I'm making a point to be careful what I allow into my backlog. If realistically we're not going to do it, it doesn't belong in the backlog. There are a lot of things I want to do that are not in the backlog because I know realistically they're just not worth it. Even with AI where you are not using your monthly token allowance, there are still a lot of things not worth doing.
Just this week I was thinking about an idea that would improve builds, let's do that refactoring. However, as I started looking into the amount of work I would require to get it done, I realized that, yes, it would be an improvement to our builds, but the cost of getting the work done is greater than the improvement is worth, and so I'm not going to go forward with it. It's too bad there are a number of annoyances that I'm going to be living with because it's not worth fixing. But that is the reality of life. I need to do things that will ultimately satisfy our customers that keep coming back and paying us more money.
How do I stop someone else from putting that back on my backlog again?
Just today I had someone open a bug on my code because they decided that the organization was wrong. Some modules should be moved from one directory to another. Never mind why they opened it as a bug, the reality is people are opening and putting stories on my backlog.
I wouldn’t delete any items any backlog items. Much better to always close with a reason. You can make this a first class status in whatever platform like a “Closed - Duplicate”, “Closed - Unneeded”, etc.
This helps with searching for rationale in the future, looking back to similar items, etc.
You can’t stop someone from putting it back but you can close it as duplicate and link it as related.
Edit: also if the person putting work in the backlog is not a core contributor or product you should formalize some other intake process that can triage whether it meets the bar to get in
If they can't justify why this is a bug, and why it's worth your time to fix this as opposed to something else, you should be able to revoke their permission to touch your backlog.
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.
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.)
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
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.
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.
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.
I'm making a point to be careful what I allow into my backlog. If realistically we're not going to do it, it doesn't belong in the backlog. There are a lot of things I want to do that are not in the backlog because I know realistically they're just not worth it. Even with AI where you are not using your monthly token allowance, there are still a lot of things not worth doing.
Just this week I was thinking about an idea that would improve builds, let's do that refactoring. However, as I started looking into the amount of work I would require to get it done, I realized that, yes, it would be an improvement to our builds, but the cost of getting the work done is greater than the improvement is worth, and so I'm not going to go forward with it. It's too bad there are a number of annoyances that I'm going to be living with because it's not worth fixing. But that is the reality of life. I need to do things that will ultimately satisfy our customers that keep coming back and paying us more money.
Just delete stuff you’re not going to do.
How do I stop someone else from putting that back on my backlog again?
Just today I had someone open a bug on my code because they decided that the organization was wrong. Some modules should be moved from one directory to another. Never mind why they opened it as a bug, the reality is people are opening and putting stories on my backlog.
I wouldn’t delete any items any backlog items. Much better to always close with a reason. You can make this a first class status in whatever platform like a “Closed - Duplicate”, “Closed - Unneeded”, etc.
This helps with searching for rationale in the future, looking back to similar items, etc.
You can’t stop someone from putting it back but you can close it as duplicate and link it as related.
Edit: also if the person putting work in the backlog is not a core contributor or product you should formalize some other intake process that can triage whether it meets the bar to get in
If they can't justify why this is a bug, and why it's worth your time to fix this as opposed to something else, you should be able to revoke their permission to touch your backlog.
Yes, but easier said than done.
A strong whiff of AI writing.
Basically OKR
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.
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.)
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
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.
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.
What is a submarine article?
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.
https://www.paulgraham.com/submarine.html