6 ms·

Submarine article. Also, back when I was still a PM I found most these kinds of tools to be a waste of time. Tools don't solve ownership. I found just talking

Submarine article. Also, back when I was still a PM I found most these kinds of tools to be a waste of time. Tools don't solve ownership. I found just talking directly with my sellers and engineers in the same room would solve these backlog issues. Every project, initiative, and task needed to be directly tied to enhancing customer satisfaction or tangibly driving revenue (1-2% of ARR). If Eng could not justify why a refactor could help customer satisfaction or topline P/L, I'd deprioritize it. If sales could not justify why a checkbox feature would satisfy the majority of our customers or help our topline P/L, I'd deprioritize it and re-prioritize the refactor. Just demand fucking ownership from everyone - PM, Sales, and Engineering - and complex projects can be easily executed. Ownership also means trusting the people executing but also validating - I trusted my engineers, salespeople, and stakeholders and vice versa, but I always made sure to do my homework. Backlogs will always expand - that's to be expected - but someone must groom them and own them. That's on the PM. Who cares what tool you use - it could be JIRA or a Excel 95 spreadsheet. Just own shit and fucking execute.

phildenhoff 14d ago
What is a submarine article?
- nemomarx 14d ago
  I can't find the article first using the term, but it's like a hidden sponsored article - start by describing a general problem that people might have or something in the technology space, end by advocating for a solution that your company (or the company who paid you to write the post) sells.
- richbell 14d ago
  https://www.paulgraham.com/submarine.html https://www.paulgraham.com/submarine.html
dzink 14d ago
So if your code is spaghetti and that makes it impossible to add new features (happens easy, especially if you let an LLM loose on it), the refactoring to fix it would never happen and the engineers who stay or are willing to be hired will just be those clueless enough not to know they won’t be able to achieve anything.
- bluGill 14d ago
  That certainly happens. On the other hand, engineers are typically way too eager to claim a spaghetti code. We need to rewrite the whole thing. After long experience, I've concluded most cases of people complaining that something needs to be written because of spaghetti code are really just somebody other than me wrote it and I disagree with some design decisions without understanding why those decisions were made in the first place and I think I can do better. I was involved with the very large rewrite some years ago. The code is now in production for 10 years, and so we call it successful. On the other hand, most of what we learned along the way of doing the rewrite was why the original code was designed that way in the first place, and so a lot of design decisions that we thought we were going to be able to rethink were designed that way for good reason in the first place. Even the places where we did make a big improvement because of what we still believe was a bad design decision in the first place. Not only could we have refactored in place to the new design but also the new design I can now say in hindsight was also a terrible idea. We're now trying to figure how to refactor in place to a third option which only time will tell if this is a good idea but we know for a fact two different ways to design this part that are not a good idea. I'm skeptical of your claim that an LLM is really going to add more Spaghetti for Code. Now, certainly, especially the LLMs of last year did a terrible job of designing code. However, they have gotten much better just in the course of one year. But even at that, most of the problem, I think, is you are not taking the time to understand what the LLM is doing in the first place. An LLM is by definition code that was not written by you and therefore it is a lot of boring and tedious effort to understand it. However, if you take the time to actually read the code, it often is perfectly understandable and just as good as code any other human right. But that other human is also not you and so if another human wrote it you would also call it spaghetti code. Good part of LMS is they are very good at refactoring code. Whether they wrote it or a human wrote it, they can do a lot of changes for you that would be tedious or take a long time to do by hand.
wrs 14d ago
A quick way to lose your engineers’ trust is to claim you “trust your engineers” and then unilaterally deprioritize an engineering task. Not saying there aren’t clueless or myopic engineers, just that you should be honest about the relationship. (And find better engineers or better product managers, whichever is needed.)
- alephnerd 14d ago
  When I was a PM, I was brutally honest about my heuristics, thinking, and product vision and made sure to give as much visibility as I could to ICs without overstepping executive leadership mandates. And if an engineer thought I was talking shit, I'd give them the option to lead low risk customer calls with me shadowing and their manager's permission so they can see the tradeoffs a business deals with on a daily basis. Either they could prove their mettle (and I'd mentor them to climb up the engineering or PM ladder) or they'd shut up once faced with the kinds of day to day tradeoffs and responsibilities comes from being a PM for an 8-9 figure product line. Of course, I always demanded full visibility into our hiring pipeline across functions because a bad hire is an expensive mistake that can kill an entire product line. Also, this was how I became a Sales Engineer and later Product Manager as a SWE. I told a VP Sales and Director of Product that they were talking out of their ass but I had a great engineering reputation internally, so they brought me in on a similar gambit. My leadership were old school Silicon Valley (they lived first hand during the Halt and Catch Fire era), but this kind of culture is still common here in the Bay. Edit: oh damn, we got Silicon Valley history makers here :0
  - wrs 13d ago
    Yeah, that sounds great — the ideal is product and engineering engaged on a common and realistic view of what the business is trying to do. You want a staff meeting where everyone’s contributing their skills to the problem, not defending or imposing their siloed concerns. If you have any function (product, engineering, legal, finance, whatever) able to, or even trying to, unilaterally impose their priorities without regard to the bigger picture, that’s not a good dynamic. Especially if it’s covered up with “teamwork” rhetoric that doesn’t match the reality.

phildenhoff 14d ago

What is a submarine article?

nemomarx 14d ago
I can't find the article first using the term, but it's like a hidden sponsored article - start by describing a general problem that people might have or something in the technology space, end by advocating for a solution that your company (or the company who paid you to write the post) sells.
richbell 14d ago
https://www.paulgraham.com/submarine.html https://www.paulgraham.com/submarine.html

dzink 14d ago

So if your code is spaghetti and that makes it impossible to add new features (happens easy, especially if you let an LLM loose on it), the refactoring to fix it would never happen and the engineers who stay or are willing to be hired will just be those clueless enough not to know they won’t be able to achieve anything.

bluGill 14d ago
That certainly happens. On the other hand, engineers are typically way too eager to claim a spaghetti code. We need to rewrite the whole thing. After long experience, I've concluded most cases of people complaining that something needs to be written because of spaghetti code are really just somebody other than me wrote it and I disagree with some design decisions without understanding why those decisions were made in the first place and I think I can do better. I was involved with the very large rewrite some years ago. The code is now in production for 10 years, and so we call it successful. On the other hand, most of what we learned along the way of doing the rewrite was why the original code was designed that way in the first place, and so a lot of design decisions that we thought we were going to be able to rethink were designed that way for good reason in the first place. Even the places where we did make a big improvement because of what we still believe was a bad design decision in the first place. Not only could we have refactored in place to the new design but also the new design I can now say in hindsight was also a terrible idea. We're now trying to figure how to refactor in place to a third option which only time will tell if this is a good idea but we know for a fact two different ways to design this part that are not a good idea. I'm skeptical of your claim that an LLM is really going to add more Spaghetti for Code. Now, certainly, especially the LLMs of last year did a terrible job of designing code. However, they have gotten much better just in the course of one year. But even at that, most of the problem, I think, is you are not taking the time to understand what the LLM is doing in the first place. An LLM is by definition code that was not written by you and therefore it is a lot of boring and tedious effort to understand it. However, if you take the time to actually read the code, it often is perfectly understandable and just as good as code any other human right. But that other human is also not you and so if another human wrote it you would also call it spaghetti code. Good part of LMS is they are very good at refactoring code. Whether they wrote it or a human wrote it, they can do a lot of changes for you that would be tedious or take a long time to do by hand.

wrs 14d ago

A quick way to lose your engineers’ trust is to claim you “trust your engineers” and then unilaterally deprioritize an engineering task. Not saying there aren’t clueless or myopic engineers, just that you should be honest about the relationship. (And find better engineers or better product managers, whichever is needed.)

alephnerd 14d ago
When I was a PM, I was brutally honest about my heuristics, thinking, and product vision and made sure to give as much visibility as I could to ICs without overstepping executive leadership mandates. And if an engineer thought I was talking shit, I'd give them the option to lead low risk customer calls with me shadowing and their manager's permission so they can see the tradeoffs a business deals with on a daily basis. Either they could prove their mettle (and I'd mentor them to climb up the engineering or PM ladder) or they'd shut up once faced with the kinds of day to day tradeoffs and responsibilities comes from being a PM for an 8-9 figure product line. Of course, I always demanded full visibility into our hiring pipeline across functions because a bad hire is an expensive mistake that can kill an entire product line. Also, this was how I became a Sales Engineer and later Product Manager as a SWE. I told a VP Sales and Director of Product that they were talking out of their ass but I had a great engineering reputation internally, so they brought me in on a similar gambit. My leadership were old school Silicon Valley (they lived first hand during the Halt and Catch Fire era), but this kind of culture is still common here in the Bay. Edit: oh damn, we got Silicon Valley history makers here :0
- wrs 13d ago
  Yeah, that sounds great — the ideal is product and engineering engaged on a common and realistic view of what the business is trying to do. You want a staff meeting where everyone’s contributing their skills to the problem, not defending or imposing their siloed concerns. If you have any function (product, engineering, legal, finance, whatever) able to, or even trying to, unilaterally impose their priorities without regard to the bigger picture, that’s not a good dynamic. Especially if it’s covered up with “teamwork” rhetoric that doesn’t match the reality.