I think introducing hierarchy is slightly helpful, but does not solve the core problem.
The core problem is that everyone in the company have an opinion on what should go into the backlog and their personal proposal should be the highest priority/hierarchy/urgency. The proposer frequently does not want to do the extra effort to research what is the deeper problem we can provide value for customers but still insists that their idea is immediately worked on. In the past, I would say 95% of the backlog dies in the status of “further research required”. Without the deeper research, the priority/hierarchy/urgency is just who is screaming louder…
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.
Which sucks because I feel there is some good stuff but it’s buried. This is going to be like every “era” on the web, isn’t it? We must be 2-3 months away from sites that people threw up simply to create the Reader Mode of the AI era, where we will all link to articles via an intermediary 12 Foot Ladder type site that runs the content through a different AI taught to boil the article to its essence and then tersely rewrite those bullet points in something close to human language.
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
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.
Yep! Totally agree with ya! We're all a team and no one is above or below each other, and I always made sure to manage out people who had a superiority complex - even if they were gifted (and they usually weren't) they would just make life hell for everyone else.
I also always fought for higher compensation - I'd rather have a couple really talented and well paid individuals rather than a mass of low paid and checked out ones.
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.
This is an ad, so it's going to be fluff, but the example use cases really stood out to me as not being very real/practical.
Right off the bat: It assumes the team has a cluttered and completely unmaintained backlog already. Even with an unmaintained backlog, Jira and other tools already have great built in tooling to help a backlog stay visually clear (priority indicator, epic tag, and the ability to make placeholder sprints for work at certain levels).
The sprint planning convo suggests that the team (engineering, qa, stakeholders, more) all have a say in determining priority of the work in every sprint planning session. Where is the PM in these calls? The PM/PO brings the "what" to sprint planning. If this cycle is happening over and over again, the Product team member is weak and being given too much of a pass. The team is likely frustrated over lack of direction.
Getting into the core premise of the flight levels approach. The 3 flight levels just decompose into a backlog that can still be large, which results in the same issue this tooling set out to solve. The 3 flight levels also don’t make it very clear for stakeholders on what the team’s actually going to deliver soon vs later. That is because this model still has everything the delivery team will do just boiled down into the backlog. It's not all bad though, the priorities and value of items will be clearer. The sprint planning sessions should go more smoothly. Finally, the 3 flight levels just make me think of the common format: epic > story > task. The flight levels don't feel like any improvement on the trusted product discovery and delivery loop. A simple period for spiking and then implementing (then looping back to iterate for improvements). Discovery is for validating ideas (spikes), prototyping, proving value, defining what to be done. This discovery work is tracked at the epic level and presented in a board or jira plan on a Gantt chart. As work becomes defined, it is broken down into stories and tasks, prioritized, and moved to the backlog. Easily allowing the team to know what to execute on next.
The team in the example seems to only be able to focus on one topic at a time. Either auth or button colors. I’ve yet to find a team that can’t handle multiple priorities (fitted into capacity of course). The team may differ from what the business wants to do. This can be solved by structuring sprint capacities around percentages. Eg 75% is for attacking the roadmap (items from discovery) and then 25% for what the delivery team identifies as necessary (like button colors). I’ve found this to be effective at ensuring a team can predictably move business work forward while also carving out time to handle infrastructure or other improvements and bug fixes that don’t normally get considered at the leadership level.
The fact is, that an organization/team that cares this much about organizing their backlog already has a solution in place.
Don’t get me started on Marty Cagan’s ideas. The practices are the fastest way to burnout for a product team. Big CEO minus all of the power and reward, but all of the responsibility energy.
This is more a critique of the article and less of the product, which I don't know anything about.
I think introducing hierarchy is slightly helpful, but does not solve the core problem. The core problem is that everyone in the company have an opinion on what should go into the backlog and their personal proposal should be the highest priority/hierarchy/urgency. The proposer frequently does not want to do the extra effort to research what is the deeper problem we can provide value for customers but still insists that their idea is immediately worked on. In the past, I would say 95% of the backlog dies in the status of “further research required”. Without the deeper research, the priority/hierarchy/urgency is just who is screaming louder…
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.
This is great when you’re the sole dev and PM. It does not scale well. Especially if you have stakeholders above you in the org chart.
Yes, but easier said than done.
A strong whiff of AI writing.
Which sucks because I feel there is some good stuff but it’s buried. This is going to be like every “era” on the web, isn’t it? We must be 2-3 months away from sites that people threw up simply to create the Reader Mode of the AI era, where we will all link to articles via an intermediary 12 Foot Ladder type site that runs the content through a different AI taught to boil the article to its essence and then tersely rewrite those bullet points in something close to human language.
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
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.
Yep! Totally agree with ya! We're all a team and no one is above or below each other, and I always made sure to manage out people who had a superiority complex - even if they were gifted (and they usually weren't) they would just make life hell for everyone else.
I also always fought for higher compensation - I'd rather have a couple really talented and well paid individuals rather than a mass of low paid and checked out ones.
I've mentored my PortCos this way as well.
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
Basically OKR
This is an ad, so it's going to be fluff, but the example use cases really stood out to me as not being very real/practical.
Right off the bat: It assumes the team has a cluttered and completely unmaintained backlog already. Even with an unmaintained backlog, Jira and other tools already have great built in tooling to help a backlog stay visually clear (priority indicator, epic tag, and the ability to make placeholder sprints for work at certain levels). The sprint planning convo suggests that the team (engineering, qa, stakeholders, more) all have a say in determining priority of the work in every sprint planning session. Where is the PM in these calls? The PM/PO brings the "what" to sprint planning. If this cycle is happening over and over again, the Product team member is weak and being given too much of a pass. The team is likely frustrated over lack of direction.
Getting into the core premise of the flight levels approach. The 3 flight levels just decompose into a backlog that can still be large, which results in the same issue this tooling set out to solve. The 3 flight levels also don’t make it very clear for stakeholders on what the team’s actually going to deliver soon vs later. That is because this model still has everything the delivery team will do just boiled down into the backlog. It's not all bad though, the priorities and value of items will be clearer. The sprint planning sessions should go more smoothly. Finally, the 3 flight levels just make me think of the common format: epic > story > task. The flight levels don't feel like any improvement on the trusted product discovery and delivery loop. A simple period for spiking and then implementing (then looping back to iterate for improvements). Discovery is for validating ideas (spikes), prototyping, proving value, defining what to be done. This discovery work is tracked at the epic level and presented in a board or jira plan on a Gantt chart. As work becomes defined, it is broken down into stories and tasks, prioritized, and moved to the backlog. Easily allowing the team to know what to execute on next.
The team in the example seems to only be able to focus on one topic at a time. Either auth or button colors. I’ve yet to find a team that can’t handle multiple priorities (fitted into capacity of course). The team may differ from what the business wants to do. This can be solved by structuring sprint capacities around percentages. Eg 75% is for attacking the roadmap (items from discovery) and then 25% for what the delivery team identifies as necessary (like button colors). I’ve found this to be effective at ensuring a team can predictably move business work forward while also carving out time to handle infrastructure or other improvements and bug fixes that don’t normally get considered at the leadership level.
The fact is, that an organization/team that cares this much about organizing their backlog already has a solution in place.
Don’t get me started on Marty Cagan’s ideas. The practices are the fastest way to burnout for a product team. Big CEO minus all of the power and reward, but all of the responsibility energy.
This is more a critique of the article and less of the product, which I don't know anything about.
[flagged]
[dead]