Scrum's “Product Owner” Problem(rethinkingsoftware.substack.com)
rethinkingsoftware.substack.com
Scrum's “Product Owner” Problem
https://rethinkingsoftware.substack.com/p/scrums-product-owner-problem
142 comments
I hear that you want to be empowered, but you want the people around you not to be.
Understanding why you think your role should be empowered (ultimately responsible for the product) and the benefits it brings is _exactly_ why the people around you should be empowered as well.
It sounds to me like you’ve never been in the software businesses where true creation is happening and you’re in the world of pseudo contractors or explicit contractor arrangements. All I can say is there is a much better world, you should change your attitude and hustle to get there.
Understanding why you think your role should be empowered (ultimately responsible for the product) and the benefits it brings is _exactly_ why the people around you should be empowered as well.
It sounds to me like you’ve never been in the software businesses where true creation is happening and you’re in the world of pseudo contractors or explicit contractor arrangements. All I can say is there is a much better world, you should change your attitude and hustle to get there.
Second, 100%. That's exactly what I'm reading as well, its why POs/PMs get a bad rep, its representative of the worst POs/PMs I've worked with, and frankly it is virally toxic.
If you view your product development as a factory floor, your product will be a mass manufactured cookie cutter widget. That's how it works, and it does work for, say, cars. But the software business isn't like the car business. Its startlingly winner takes all. Atlassian builds a better, more efficient widget factory than you do for tasking software, and they eat the tasking software market, and they shoot tendrils out into other markets, and soon your business is dead.
If you view your product development as a factory floor, your product will be a mass manufactured cookie cutter widget. That's how it works, and it does work for, say, cars. But the software business isn't like the car business. Its startlingly winner takes all. Atlassian builds a better, more efficient widget factory than you do for tasking software, and they eat the tasking software market, and they shoot tendrils out into other markets, and soon your business is dead.
Explain the toxic piece a little more for me. Why do you see that?
And I think a lot of software IS mass produced cookie cutter widgets. Especially in the SaaS space. The truly special stuff is only a small percentage of the total product.
And I think a lot of software IS mass produced cookie cutter widgets. Especially in the SaaS space. The truly special stuff is only a small percentage of the total product.
For starters: The old notion that engineers aren't good with people so don't let them talk to stakeholders [1]; so you end up with PMs/POs/EMs holding a monopoly on information gathering from stakeholders, which is at-best inefficient and more realistically less accurate.
It becomes "viral" (it spreads) when it becomes institutionalized; when leaders say "no we want you focused on the code, so go into the basement and we'll talk in our 1-1 about your progress". People skills are a skill; its right there in the name, it needs to be developed and exercised. If you don't let your engineers out of the basement, you get engineers with bad people skills, and the prophecy writes itself. Those engineers with bad people skills prioritize the skills they have in themselves when hiring others, and so on, and so forth.
This isn't me arguing that these PM/EM/PO roles shouldn't exist, to be clear; its more-so things that bad individuals in those roles may do. That being said, I do feel that the healthiest, most productive software teams I've been on had a few things in common: Less technical EMs, combination EM+PMs, or sharing a PM across multiple related teams in the same department.
[1] https://www.youtube.com/watch?v=hNuu9CpdjIo
It becomes "viral" (it spreads) when it becomes institutionalized; when leaders say "no we want you focused on the code, so go into the basement and we'll talk in our 1-1 about your progress". People skills are a skill; its right there in the name, it needs to be developed and exercised. If you don't let your engineers out of the basement, you get engineers with bad people skills, and the prophecy writes itself. Those engineers with bad people skills prioritize the skills they have in themselves when hiring others, and so on, and so forth.
This isn't me arguing that these PM/EM/PO roles shouldn't exist, to be clear; its more-so things that bad individuals in those roles may do. That being said, I do feel that the healthiest, most productive software teams I've been on had a few things in common: Less technical EMs, combination EM+PMs, or sharing a PM across multiple related teams in the same department.
[1] https://www.youtube.com/watch?v=hNuu9CpdjIo
Just my two cents, I don’t think that PMs or Product people don’t have a place… I really value them. I want to have collaborative discussions where I can bat the idea of what is best for the product, the long term health of the software, and the customer around… and I don’t want to do it into the mirror by myself.
But I’ve got no time, not one single second for the style of PM that ungreased is advocating for. Where the PM thinks I’m some monkey they feed tickets to, pull the lever and get code from. Early in my career I’d just leave for the next better thing, now I’ll actively make sure you’re not in my org killing the culture.
PMs are crap at architecture, crap at maintaining code, crap at fighting tech debt, crap at all the meta things that make software last… Honestly expectedly so. Y’all should argue for your side and have us as a counter weight… what ungreased is describing is irreparable. That’s why I said get out, but only if ungreased is actually good. Otherwise stay there. Keep making your shit devs miserable until they leave.
But I’ve got no time, not one single second for the style of PM that ungreased is advocating for. Where the PM thinks I’m some monkey they feed tickets to, pull the lever and get code from. Early in my career I’d just leave for the next better thing, now I’ll actively make sure you’re not in my org killing the culture.
PMs are crap at architecture, crap at maintaining code, crap at fighting tech debt, crap at all the meta things that make software last… Honestly expectedly so. Y’all should argue for your side and have us as a counter weight… what ungreased is describing is irreparable. That’s why I said get out, but only if ungreased is actually good. Otherwise stay there. Keep making your shit devs miserable until they leave.
The way I look at it is: Software companies which lean-into rather than fight against an engineer-centric corporate architecture will be better-setup to be more productive and ship higher quality product than any other architecture. They won't always be, every company is different, but its the best starting place because at the end of the day your engineers are your bottleneck. The engineers implement asks from Product Managers, Owners, Designers, Leadership, Marketing, Sales, Customers, Vendors, other Engineers/Themselves, all of these sources of work flow downhill to engineering and need to be triaged and prioritized.
So, at least for the roles engineers work most closely with (PM/PO/Designer/etc), it is productive and good that these roles are framed in the perspective that they're a service & asset role for engineering; that when engineering needs designs, they go to a designer, that when engineers need an answer to some product behavior question, they go to the PM, who would reasonably be if not the source of truth at least the authority of that domain, etc. That's only subtly different, but definitely meaningfully, than what the GP poster was saying about running the sprint board and controlling what work gets taken on; PMs/POs shouldn't have that authority, that authority lies with the EM and their discussions with the priorities of leadership.
And, by the way: calling back to my previous comment, I've worked in roles where the EMs were less-technical more-product, call these companies "product led companies", and each team had almost a bi-archy of an Engineering Manager + Engineering Lead representing two sides of this coin. This works really well. If you want a product-biased company, hire product-minded managers, but give engineers a 10-20 year title track that doesn't involve management. If you want an engineering-biased company, promote or hire engineers; this can work for more hard-tech infrastructural companies. If you struggle to find great talent, hire dedicated PMs but have them report to your product or engineering-minded EMs. That's it.
So, at least for the roles engineers work most closely with (PM/PO/Designer/etc), it is productive and good that these roles are framed in the perspective that they're a service & asset role for engineering; that when engineering needs designs, they go to a designer, that when engineers need an answer to some product behavior question, they go to the PM, who would reasonably be if not the source of truth at least the authority of that domain, etc. That's only subtly different, but definitely meaningfully, than what the GP poster was saying about running the sprint board and controlling what work gets taken on; PMs/POs shouldn't have that authority, that authority lies with the EM and their discussions with the priorities of leadership.
And, by the way: calling back to my previous comment, I've worked in roles where the EMs were less-technical more-product, call these companies "product led companies", and each team had almost a bi-archy of an Engineering Manager + Engineering Lead representing two sides of this coin. This works really well. If you want a product-biased company, hire product-minded managers, but give engineers a 10-20 year title track that doesn't involve management. If you want an engineering-biased company, promote or hire engineers; this can work for more hard-tech infrastructural companies. If you struggle to find great talent, hire dedicated PMs but have them report to your product or engineering-minded EMs. That's it.
I don’t think I made that argument. I’m advocating for focus from the engineers. Focus on architecture, code quality, tech debt, etc.
Focus on that stuff also means NOT having engineers doing other things, like sitting in a booth at a conference, playing with color schemes in Figma, creating financial projections for a new feature, etc, etc.
Engineers should do what they’re good at, and POs should do what they’re good at. Side quests are fun, but don’t help the business work efficiently.
Focus on that stuff also means NOT having engineers doing other things, like sitting in a booth at a conference, playing with color schemes in Figma, creating financial projections for a new feature, etc, etc.
Engineers should do what they’re good at, and POs should do what they’re good at. Side quests are fun, but don’t help the business work efficiently.
Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance. In a high-functioning information systems organization, the programmer's job is one of simple translation from specifications into code; those specifications will have been produced via stepwise refinement by systems analysts who do understand the business and the people within it.
See the late Tim Bryce's Theory P essay: https://www.phmainstreet.com/mba/ss050117.pdf and note that he uses the exact same "artists vs. house painters" analogy. Before his retirement Tim had been managing large software projects since before much of Hackernews was born, and had forgotten more than most internet commenters know about what it takes to manage a successful project.
The "software businesses where true creation is happening" are few and far between -- Apple, maybe Google at its peak, and a handful of others. They are run by geniuses, typically from top-tier schools like MIT and Stanford. They are not the typical software organization. The typical software organization produces the software that keeps civilization humming -- and doing that is a proven, teachable, scientific process. Lately we've seen many organizations that should be doing this instead cosplaying as a bunch of genius disruptors, but they have nowhere near the brainpower to actually pull it off, and the world has gone to hell in a handbasket as a result.
See the late Tim Bryce's Theory P essay: https://www.phmainstreet.com/mba/ss050117.pdf and note that he uses the exact same "artists vs. house painters" analogy. Before his retirement Tim had been managing large software projects since before much of Hackernews was born, and had forgotten more than most internet commenters know about what it takes to manage a successful project.
The "software businesses where true creation is happening" are few and far between -- Apple, maybe Google at its peak, and a handful of others. They are run by geniuses, typically from top-tier schools like MIT and Stanford. They are not the typical software organization. The typical software organization produces the software that keeps civilization humming -- and doing that is a proven, teachable, scientific process. Lately we've seen many organizations that should be doing this instead cosplaying as a bunch of genius disruptors, but they have nowhere near the brainpower to actually pull it off, and the world has gone to hell in a handbasket as a result.
Maybe, just maybe, you're mixing cause and effect.
If you treat developers like house painters, they will not give you more. They will build the spec that you give them, and hold their tongues when they know it's a bad user experience.
If you treat developers like co-creators, and hire explicitly, and you put them in the same room with customers, you get a group thinking about how to solve a problem that your users have. They may be able to deliver something quicker, or develop a better customer experience, or question assumptions that lead to a better product.
An empowered engineer will be able to ask, "but what about how this user uses the software? Will this work for them?" And they become great at that by getting experience doing this - it's a skill, not an inborn talent.
If you treat developers like house painters, they will not give you more. They will build the spec that you give them, and hold their tongues when they know it's a bad user experience.
If you treat developers like co-creators, and hire explicitly, and you put them in the same room with customers, you get a group thinking about how to solve a problem that your users have. They may be able to deliver something quicker, or develop a better customer experience, or question assumptions that lead to a better product.
An empowered engineer will be able to ask, "but what about how this user uses the software? Will this work for them?" And they become great at that by getting experience doing this - it's a skill, not an inborn talent.
Precisely, I've worked at a couple of places where software developers were treated like assembly line workers who convert tickets into code, and on one occasion I was even told that it wasn't my job to ask questions designed to improve my big-picture understanding of the problem, use-cases, etc.
I feel like the "programmers only care about code" trope is perpetuated by people who aren't good at sharing knowledge, or who lack intimate understanding of their customers' needs themselves and have to resort to pointing fingers.
Some programmers are like that, certainly, but if most developers one comes across are like that then one might have to look inwards.
I feel like the "programmers only care about code" trope is perpetuated by people who aren't good at sharing knowledge, or who lack intimate understanding of their customers' needs themselves and have to resort to pointing fingers.
Some programmers are like that, certainly, but if most developers one comes across are like that then one might have to look inwards.
Tangent: There's a Star Trek clip I wish I could find online so I'd have it on-hand to show non-technical people. It's from the 90s, in an episode of Deep Space Nine.
Worf (in Security) is having trouble dealing with Engineering, and O'Brien gives him some advice, something along the lines of "Engineers like to solve problems. Instead of telling them what to do, tell them what you need and let them figure it out.". Then later when he tries it out, they come up with a solution he wouldn't have thought of.
Worf (in Security) is having trouble dealing with Engineering, and O'Brien gives him some advice, something along the lines of "Engineers like to solve problems. Instead of telling them what to do, tell them what you need and let them figure it out.". Then later when he tries it out, they come up with a solution he wouldn't have thought of.
> In a high-functioning information systems organization, the programmer's job is one of simple translation from specifications into code;
That's not a job, that's a tool, and it's called a transpiler.
A "high functioning organization" fitting your description wouldn't need to have any salaried programmers after they created that simple specification-to-code compiler.
> Their social skills are very often lacking, and they are prone to arrogance
Unlike your own comment which displays these exact qualities?
That's not a job, that's a tool, and it's called a transpiler.
A "high functioning organization" fitting your description wouldn't need to have any salaried programmers after they created that simple specification-to-code compiler.
> Their social skills are very often lacking, and they are prone to arrogance
Unlike your own comment which displays these exact qualities?
> Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer
“Programmers” are not, software developers/software engineers, who are more like systems analysts than programmers in scope of job role at the full working level, though generally employed in organizations that do not also employ separate programmers, however, are and should be.
The kind of organization with wide organization/and interaction distance between users and people working on code with large numbers of over-the-wall handoffs in between is obsolete in many areas of software development because of advances in tooling, because of recognition of the quality costs imposed by that structure given the dynamics of many application domains where whiteboard analysis without real active use is not effective in getting accurate requirements, and because of the costs of that organization style which has long cycle times and high coordination overhead.
“Programmers” are not, software developers/software engineers, who are more like systems analysts than programmers in scope of job role at the full working level, though generally employed in organizations that do not also employ separate programmers, however, are and should be.
The kind of organization with wide organization/and interaction distance between users and people working on code with large numbers of over-the-wall handoffs in between is obsolete in many areas of software development because of advances in tooling, because of recognition of the quality costs imposed by that structure given the dynamics of many application domains where whiteboard analysis without real active use is not effective in getting accurate requirements, and because of the costs of that organization style which has long cycle times and high coordination overhead.
That's why I don't work with programmers in this capacity, programming is the simple part. I work with software engineers, and the best of them probably didn't even open an IDE this week yet. I don't need them to code, I need them to tell the programmers what and how to code.
I think programmer vs software engineer is one of those semantic things that might sound witty but ultimately has little utility or shared agreement. Job listings use them interchangeably. I call myself a programmer in casual conversation because it's easier and I'd feel kind of pompous saying "software engineer", even though I'm firmly on the "software engineer" side at this point.
And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE. I'd be worried I'm working under someone out of touch, too far removed from the actualization of software. Isn't that how we got the EnterpriseBeanFactoryFactory stereotype? The best team leads and architects I know still spend a lot of their time coding. One famous example is Carmack.
And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE. I'd be worried I'm working under someone out of touch, too far removed from the actualization of software. Isn't that how we got the EnterpriseBeanFactoryFactory stereotype? The best team leads and architects I know still spend a lot of their time coding. One famous example is Carmack.
> And it sounds a little incredulous for even a senior architect to go an entire week without opening an IDE.
Not really. I'm at least two levels below that and about a month ago I spent 3 days straight building a document and diagrams to convince an architect that recently joined our team that one of his plans for us was bad. (Part of the reason it took so long because I had to straighten out some thoughts and figure out how to organize years of experience that has just been building in my head over time, plus come up with alternate plans that were a better way of getting to a similar-but-not-quite-the-same end goal)
I don't remember what I was doing before and after that but it wouldn't surprise me if I hadn't touched any code for over a week.
On the flipside since then I've been deep into code, doing some re-architecting of our development stack to make it easier to work with.
Basically there's just no consistency day-to-day.
Not really. I'm at least two levels below that and about a month ago I spent 3 days straight building a document and diagrams to convince an architect that recently joined our team that one of his plans for us was bad. (Part of the reason it took so long because I had to straighten out some thoughts and figure out how to organize years of experience that has just been building in my head over time, plus come up with alternate plans that were a better way of getting to a similar-but-not-quite-the-same end goal)
I don't remember what I was doing before and after that but it wouldn't surprise me if I hadn't touched any code for over a week.
On the flipside since then I've been deep into code, doing some re-architecting of our development stack to make it easier to work with.
Basically there's just no consistency day-to-day.
It was meant to be mostly a joke, I agree it's vague and I do the same as you do. Though the point stands - very senior or principal engineers/developers/architects are not there to write code.
A team lead should be hands on, I agree. But there are also technical people who operate above teams and even above departments - those probably don't code much. Most of their time is probably spent in business/strategy meetings and writing stuff in Jira and Confluence.
A principal engineer can be on the same hierarchy/influence level as a very senior manager or director, leading hundreds of people.
A team lead should be hands on, I agree. But there are also technical people who operate above teams and even above departments - those probably don't code much. Most of their time is probably spent in business/strategy meetings and writing stuff in Jira and Confluence.
A principal engineer can be on the same hierarchy/influence level as a very senior manager or director, leading hundreds of people.
> Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance.
This seems like a problem that can be solved during hiring. These are not necessarily attributes of programmers in general, maybe just the ones you are finding.
I've worked at companies where Product and Engineering roles were separate, and information had to pass between the two in the form of docs, conversations, specs, charts and so on. I've also worked at companies where there was no dedicated product role: Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything. Honestly I think that way works better, because there is no necessary back-and-forth negotiation about priorities, features, and quality (except what goes on in the tech lead's own mind). No need to have some separate person go talk to the customer and deliver requirements to engineering on a platter. It's much more efficient. You just need to hire the engineers who are not just ticket-implementors, but who can also do the product and business work.
This seems like a problem that can be solved during hiring. These are not necessarily attributes of programmers in general, maybe just the ones you are finding.
I've worked at companies where Product and Engineering roles were separate, and information had to pass between the two in the form of docs, conversations, specs, charts and so on. I've also worked at companies where there was no dedicated product role: Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything. Honestly I think that way works better, because there is no necessary back-and-forth negotiation about priorities, features, and quality (except what goes on in the tech lead's own mind). No need to have some separate person go talk to the customer and deliver requirements to engineering on a platter. It's much more efficient. You just need to hire the engineers who are not just ticket-implementors, but who can also do the product and business work.
> Engineering was responsible for the implementation, the design, the product-market fit, the customer need, everything.
I generally agree but it's a tough sell hiring talented people as effectively one man startups with no equity.
Plus, without UBI it's not fair to remove so much organizational padding: getting paid to decorate JIRA boards may not bring any value but it keeps someone's family fed.
I generally agree but it's a tough sell hiring talented people as effectively one man startups with no equity.
Plus, without UBI it's not fair to remove so much organizational padding: getting paid to decorate JIRA boards may not bring any value but it keeps someone's family fed.
You’re on hackernews, not an MBA roundtable. Lot of people here have been at Apple (like me), Google (at its peak in your opinion or now) and let me queue you in on something… the leaders at Google, Apple, etc that you’re lionizing spoke about their developers the way I am. Maybe that is the gap between the typical org and the great ones
[deleted]
Blaming enshittification, rent-seeking and blatant conflicts of interest on... SWEs with overly high opinions of their business acumen is certainly a bold claim.
Where this breaks down, as I've experienced at least, is that the product management side maintains basically zero awareness of the production constraints engineers are working within. If you've built out a painting production line around spray guns and beige, that has knock-on effects as to what results are attainable. A PM asking for polka-dots next sprint is throwing into question the entire body of practice, but this happens with extreme frequency in software.
This I think is a broader problem of a certain personality of "idea guys" that lie about requirements, often without being aware of it, and it being our problem as engineers to read their minds and be two steps ahead of them.
Director: "We need a factory that's tooled around manufacturing boxes of cookies with blue frosting. We don't need any other colors, just blue frosting!"
Junior Engineer: "He's going to come back in two days and ask for red frosting. Better make sure it can do any color."
Mid Level Engineer: "He's going to come back in a week and ask us for multi-color boxes. Better make sure it can do any combination of colors in each box."
Senior Engineer: "He's going to have the big idea to add sprinkles, writing, and branch out into eclairs. Better make sure the factory is extensible and can retool itself per-batch to make each box to-order."
The worst part about this is you can see where uncertainty leads to over-engineering and consequences if your psychic senses are off. This is where a good PM steps in and forces folks like this into a roadmap on a long-enough time-scale that you can see the mid-level's design is all we'll need. And if you still want eclairs we can talk about that in 2026.
Director: "We need a factory that's tooled around manufacturing boxes of cookies with blue frosting. We don't need any other colors, just blue frosting!"
Junior Engineer: "He's going to come back in two days and ask for red frosting. Better make sure it can do any color."
Mid Level Engineer: "He's going to come back in a week and ask us for multi-color boxes. Better make sure it can do any combination of colors in each box."
Senior Engineer: "He's going to have the big idea to add sprinkles, writing, and branch out into eclairs. Better make sure the factory is extensible and can retool itself per-batch to make each box to-order."
The worst part about this is you can see where uncertainty leads to over-engineering and consequences if your psychic senses are off. This is where a good PM steps in and forces folks like this into a roadmap on a long-enough time-scale that you can see the mid-level's design is all we'll need. And if you still want eclairs we can talk about that in 2026.
Seasoned Engineer: "He's going to come back in a week and ask for croissants, better focus on just making blue cookies now and worry about the future later".
This. Engineers talk about feature creep, but forget to mention configuration creep. You can make anything you want! Yes it’s taken two years and no we didn’t nail the principal usecase. But we can make a version 2!
Ideally engineers should have a sense of the business and so know which are expected feature creep and which are unlikely.
So you design the blue cookies, but you leave extra space because next week you will be installing more paint guns so you can do more colors, but you limit it to 6 colors and when the CEO asks for more say we are out of space, do you really want to invest in more colors, eliminate and existing one, or the new idea.
Crescents may be a good investment, are they likely enough and similar enough to do them on the same line. (if you cookies have nuts the correct answer might be we want a whole new factory even if there is commonality just so we don't need the "nuts also used in the facility that" makes this label)
Don't leave extra space. Ask the question and get a "no, we don't need that", then call out the frequent specification misses when the schedule slips due to all the rework. (Or that doesn't happen and realize they might know what they are doing)
Pain like this is critical feedback for a organization. Blunting it hurts more in the long term.
Pain like this is critical feedback for a organization. Blunting it hurts more in the long term.
[deleted]
> Ideally, I want engineers focused on building, not taking discovery meetings with potential customers, messing around in Figma, projecting financials, writing ads, or any other role.
Maybe engineers shouldn't be bothering writing ads, or projecting financials
But if you want good builders, they should absolutely be in contact with the clients and building mockups (which you describe as messing around in Figma)
Assembly line style development where devs just churn through endless tickets is fine for junior devs but cannot be what your senior and principal devs are doing.
Maybe engineers shouldn't be bothering writing ads, or projecting financials
But if you want good builders, they should absolutely be in contact with the clients and building mockups (which you describe as messing around in Figma)
Assembly line style development where devs just churn through endless tickets is fine for junior devs but cannot be what your senior and principal devs are doing.
There are many different engineers with many different interests. Some senior engineers should be talking to clients, but some should in no way be allowed to talk to them. Some senior engineers get there by knowing the client. Some get there by make the code "better". Some get there by creating tools everyone else uses. Some get there by digging into the really hard problems. Some get there by mentoring others. Some get there by figuring out the big picture and building an architecture that works better. Some get there by figuring out priorities and getting the real important stuff done. Some get there by writing ads, projecting financials, messing with Figma. I'm sure there is more that I can't think of now.
There is nothing wrong with anything on the above list. Depending on your situation some will be more important than others. It is not possible for one person to do everything in the above list well, though often you need to do more than one. Some of them are better done by departments - but if an engineer is interested does it matter (sometimes it does, sometimes it doesn't). Your junior engineers should be thinking about what they like and what is needed - then positioning themselves to their future senior role.
The only really bad thing is when a mid level engineer is so good at something that you don't realize how important they are and so don't promote them to senior much less principal. (bad because when they leave that you didn't promote them is a sign to others you don't care about that and so the juniors didn't study it to become a backup - if you really don't care then you should be talking to that person about their waste of time side activity)
There is nothing wrong with anything on the above list. Depending on your situation some will be more important than others. It is not possible for one person to do everything in the above list well, though often you need to do more than one. Some of them are better done by departments - but if an engineer is interested does it matter (sometimes it does, sometimes it doesn't). Your junior engineers should be thinking about what they like and what is needed - then positioning themselves to their future senior role.
The only really bad thing is when a mid level engineer is so good at something that you don't realize how important they are and so don't promote them to senior much less principal. (bad because when they leave that you didn't promote them is a sign to others you don't care about that and so the juniors didn't study it to become a backup - if you really don't care then you should be talking to that person about their waste of time side activity)
If all you are interested in doing is churning out code then that's fine, but we shouldn't consider be promoting you into higher and higher roles
Higher roles implies greater responsibilities, not just to the product but also to your team and your company. That means you cannot just be an assembly line code slinger anymore. You have to talk to people, mentor people, figure out what the higher level company goals are, figure out what the product needs to meet those goals, etc
None of that just happens without communication skills
Higher roles implies greater responsibilities, not just to the product but also to your team and your company. That means you cannot just be an assembly line code slinger anymore. You have to talk to people, mentor people, figure out what the higher level company goals are, figure out what the product needs to meet those goals, etc
None of that just happens without communication skills
If you read my list you discover that some of them require far more communication skills than others.
I think these debates wind up missing the middle zone, partially because there's not a one size fits all in terms of teams and scope relative to a company. Specifically the issue I've found is that while I agree Product needs to be steering the ship, that Product Representatives find their way too far down the hierarchy.
Or another way of looking at it: On a typical team one often finds a PO, Scrum Master, and a Tech Lead. The PO reports upwards to a broader PM. The TL reports upwards to a broader EM. I'd contend those are 3 people filling the duties of what should be 1 or 2 people's worth of duties.
Imagine there's a PM at a company responsible for some portion of a/the product. And suppose there are 3 dev teams working towards it. In my mind there should be a PM for that product, detailing the what and (idealized) when. They're the ones talking to customers, coordinating with other PMs in the company, etc.
But their involvement with engineering should end at the sprint level. Instead what I've found is there's often a lower level "PO" who attends daily standups, will debate micro-level prioritization (do this before that), etc. And to me this really should be at the team/team lead level to decide. What's more, I've pretty much *never* seen this "PO" persona do any outward facing customer work - they're almost always just representatives of the broader PM organization.
As an engineer and engineering lead who has complained about product, *this* is what I'm complaining about. You're 100% correct that I don't want to be deep diving into the product side of the fence. But I'm usually in tune well enough that I don't need 2-3 layers of Product Bureaucracy between my team and the people who are doing said deep dive.
Or another way of looking at it: On a typical team one often finds a PO, Scrum Master, and a Tech Lead. The PO reports upwards to a broader PM. The TL reports upwards to a broader EM. I'd contend those are 3 people filling the duties of what should be 1 or 2 people's worth of duties.
Imagine there's a PM at a company responsible for some portion of a/the product. And suppose there are 3 dev teams working towards it. In my mind there should be a PM for that product, detailing the what and (idealized) when. They're the ones talking to customers, coordinating with other PMs in the company, etc.
But their involvement with engineering should end at the sprint level. Instead what I've found is there's often a lower level "PO" who attends daily standups, will debate micro-level prioritization (do this before that), etc. And to me this really should be at the team/team lead level to decide. What's more, I've pretty much *never* seen this "PO" persona do any outward facing customer work - they're almost always just representatives of the broader PM organization.
As an engineer and engineering lead who has complained about product, *this* is what I'm complaining about. You're 100% correct that I don't want to be deep diving into the product side of the fence. But I'm usually in tune well enough that I don't need 2-3 layers of Product Bureaucracy between my team and the people who are doing said deep dive.
[deleted]
> I have to disagree with the central argument, which is to give engineers more product management responsibilities
How is it disagreeable? Scrum is a formalization of Agile, which is literally about eliminating management by giving engineers control over the project. They are intrinsically linked. It doesn't make sense otherwise.
The Twelve Principles, is pretty clear that you need special people to make Agile work; that it's not for everyone. Your assessment that you don't want to go down that road is going to be true in the vast majorly of cases, and nothing in the literature disagrees with that. However, in those cases you wouldn't be using Scrum in the first place. It is clearly the wrong tool for the job if you are going to retain managers.
How is it disagreeable? Scrum is a formalization of Agile, which is literally about eliminating management by giving engineers control over the project. They are intrinsically linked. It doesn't make sense otherwise.
The Twelve Principles, is pretty clear that you need special people to make Agile work; that it's not for everyone. Your assessment that you don't want to go down that road is going to be true in the vast majorly of cases, and nothing in the literature disagrees with that. However, in those cases you wouldn't be using Scrum in the first place. It is clearly the wrong tool for the job if you are going to retain managers.
The article and commenter are talking about a single management role, Product. You say “retain managers” — plural. You’re putting words in their mouth.
They had something like Extreme Programming, and it was not a good time from what I heard. If you want to live in la la land of coding for a profitable business, well, sorry to break it to you, but a cohort of smart people need to be led. Notice I said led, not managed.
Also, the role is called Product Owner not Product Manager, I would imagine that was a conscious choice. If a PO feels like a manager, that’s what’s wrong. And maybe why that could be is the engineering team’s fault for having an insatiable need to.. control all aspects of their day-to-day. However, it’s a business at the end of the day, not a coding playground.
The article is basically suggesting POs shouldn’t control the backlog because engineers know better (essentially). Sounds like they’ve had a bad experience and want to vent about it. Fine, but it’s an immature take imho.
I am an engineer myself and I think it’s insulting to the people who have to take the work that engineers do (or fail to do because they want to experiment) and cross the divide and tell the business that the work you’ve done is worth everyone’s salary.
I don’t want to control the backlog with a bunch of other knuckleheads, thanks.
They had something like Extreme Programming, and it was not a good time from what I heard. If you want to live in la la land of coding for a profitable business, well, sorry to break it to you, but a cohort of smart people need to be led. Notice I said led, not managed.
Also, the role is called Product Owner not Product Manager, I would imagine that was a conscious choice. If a PO feels like a manager, that’s what’s wrong. And maybe why that could be is the engineering team’s fault for having an insatiable need to.. control all aspects of their day-to-day. However, it’s a business at the end of the day, not a coding playground.
The article is basically suggesting POs shouldn’t control the backlog because engineers know better (essentially). Sounds like they’ve had a bad experience and want to vent about it. Fine, but it’s an immature take imho.
I am an engineer myself and I think it’s insulting to the people who have to take the work that engineers do (or fail to do because they want to experiment) and cross the divide and tell the business that the work you’ve done is worth everyone’s salary.
I don’t want to control the backlog with a bunch of other knuckleheads, thanks.
> You say “retain managers” — plural. You’re putting words in their mouth.
The only use of "managers" was with respect to the use of Scrum itself, which is only tangentially related to what came before it. It logically cannot put words into anyone's mouth as it is not directly related to any mouths that may be near. It is only directly related to the comment that it is contained within by the additional context it setup.
> The article is basically suggesting POs shouldn’t control the backlog because engineers know better (essentially).
Yes, that is what Agile also says. Of course, it also says that you need the right people. We need to know more about the specific engineers to know if it is a valid take. Statistically it won't be, but perhaps it is under his unique circumstances? It is invalid to conflate his situation with someone else's.
> Sounds like they’ve had a bad experience and want to vent about it. Fine, but it’s an immature take imho.
I know Agile isn't cool anymore, but there was a time where the industry as a whole actually tried to embrace it. It wasn't considered immature then. Perhaps it is immature now only because it is no longer in fashion?
> I am an engineer myself and I think it’s insulting
If you are insulted by words on a screen, you might need to think about it harder. That is not logically sound.
The only use of "managers" was with respect to the use of Scrum itself, which is only tangentially related to what came before it. It logically cannot put words into anyone's mouth as it is not directly related to any mouths that may be near. It is only directly related to the comment that it is contained within by the additional context it setup.
> The article is basically suggesting POs shouldn’t control the backlog because engineers know better (essentially).
Yes, that is what Agile also says. Of course, it also says that you need the right people. We need to know more about the specific engineers to know if it is a valid take. Statistically it won't be, but perhaps it is under his unique circumstances? It is invalid to conflate his situation with someone else's.
> Sounds like they’ve had a bad experience and want to vent about it. Fine, but it’s an immature take imho.
I know Agile isn't cool anymore, but there was a time where the industry as a whole actually tried to embrace it. It wasn't considered immature then. Perhaps it is immature now only because it is no longer in fashion?
> I am an engineer myself and I think it’s insulting
If you are insulted by words on a screen, you might need to think about it harder. That is not logically sound.
The whole industry faces very real problems managing a large project. Agile promised to make thing better and nothing else did (lots of things before made the same promise - and failed to deliver), so on a few small success stories the industry jumped. However we are now realizing that despite some good ideas, agile didn't deliver the promise we wanted. That doesn't mean agile is bad just that it wasn't the "silver bullet" management wanted.
I don't think agile itself made all the promises that large projects wanted. However it made a few and then consultants seeing money jumped in and made more promises. Often agile couldn't deliver on the promises because there is good reason large projects can't allow engineers control over some of the things agile demanded engineers control.
Everyone wants to throw out Agile. However I don't see anything to replace it.
I don't think agile itself made all the promises that large projects wanted. However it made a few and then consultants seeing money jumped in and made more promises. Often agile couldn't deliver on the promises because there is good reason large projects can't allow engineers control over some of the things agile demanded engineers control.
Everyone wants to throw out Agile. However I don't see anything to replace it.
> That doesn't mean agile is bad just that it wasn't the "silver bullet" management wanted.
Managers didn't want to be eliminated? Who'd a thunk it. Which is also why Agile is oft considered "bad" as management by and large never actually walked away, they just pushed some of workload off onto developers under the guise of "Agile" and half-ass adopted tools designed for a flat organizational structure in a hierarchical structure with all of the impedance mismatches to go along with that.
> Everyone wants to throw out Agile. However I don't see anything to replace it.
It's not so much that anyone, non-manager at least, wants to throw out Agile per se, but in this high (relatively, at least) interest rate environment there is more of a crackdown on the work people are doing, so managers are trying to reel back in the boring work they earlier tried to outsource onto developers in order to continue to justify their jobs. That is what has replaced it, so to speak.
Managers didn't want to be eliminated? Who'd a thunk it. Which is also why Agile is oft considered "bad" as management by and large never actually walked away, they just pushed some of workload off onto developers under the guise of "Agile" and half-ass adopted tools designed for a flat organizational structure in a hierarchical structure with all of the impedance mismatches to go along with that.
> Everyone wants to throw out Agile. However I don't see anything to replace it.
It's not so much that anyone, non-manager at least, wants to throw out Agile per se, but in this high (relatively, at least) interest rate environment there is more of a crackdown on the work people are doing, so managers are trying to reel back in the boring work they earlier tried to outsource onto developers in order to continue to justify their jobs. That is what has replaced it, so to speak.
Upper management wants to get things done (and their golf game/whatever they do). They see software is expensive, late, and buggy.
Each middle manager wants to be the person who delivers and thus gets a promotion (eventually leading to upper management). If they eliminate other middle managers on the way that is okay (depending on politics of course).
Each middle manager wants to be the person who delivers and thus gets a promotion (eventually leading to upper management). If they eliminate other middle managers on the way that is okay (depending on politics of course).
Yes, you bring up a good point about the other practical issue with adopting Agile. It says that the developers and the business people need to work together daily, as becomes necessary when there isn't a manager to act as the go-between, but as you point out the business people in reality just want to play golf, not become shared participants in the development process.
But, again, Agile is pretty clear that it requires special people. It was never meant for everyone. To observe it in a light where it is applicable to all organizations violates its very existence.
But, again, Agile is pretty clear that it requires special people. It was never meant for everyone. To observe it in a light where it is applicable to all organizations violates its very existence.
Engineers are as emotional as anyone else.
> Scrum is a formalization of Agile
Scrum is one kind of Agile. Kanban is another. I think I remember there being a third, but not sure about that.
Scrum is one kind of Agile. Kanban is another. I think I remember there being a third, but not sure about that.
You're thinking of Extreme Programming (XP). Many of the Manifesto group participants came from that camp. You might say that Agile is mostly based off of XP as a result, although Schwaber is certainly among the signatories.
Kanban comes from the manufacturing world. You might find some overlap with Agile, but is not directly associated. Agile is abundantly clear that it is about software.
And yes, if you want to be pedantic, it might be more accurate to say that Agile is a generalization of XP and Scrum, rather than XP and Scrum being formalizations. Agile was written after. But I'm not sure that changes the intent of the original comment.
Kanban comes from the manufacturing world. You might find some overlap with Agile, but is not directly associated. Agile is abundantly clear that it is about software.
And yes, if you want to be pedantic, it might be more accurate to say that Agile is a generalization of XP and Scrum, rather than XP and Scrum being formalizations. Agile was written after. But I'm not sure that changes the intent of the original comment.
> Product owner isn’t a dictator, but they are ultimately responsible for the product.
they are accountable for the product.
when there’s a problem, they’re the ones who take the schtick for it.
engineers are responsible for the product.
they are the ones who fix the problem the product owner is getting schtick for.
accountability always goes up, responsibility always goes down.
this may seem like a nitpick. but it’s an important nitpick.
because the more accountable someone is made for something they care about, the more invested they are in making it succeed.
a lot of engineers care very deeply about the things they are making.
they are accountable for the product.
when there’s a problem, they’re the ones who take the schtick for it.
engineers are responsible for the product.
they are the ones who fix the problem the product owner is getting schtick for.
accountability always goes up, responsibility always goes down.
this may seem like a nitpick. but it’s an important nitpick.
because the more accountable someone is made for something they care about, the more invested they are in making it succeed.
a lot of engineers care very deeply about the things they are making.
You are correct. That’s what I meant but the wording should have been more precise.
The underlying problem is how this essay uses the word "own", which is as dictation. In almost any context, ownership should primarily about responsibility for the outcome, with the minimum authority necessary to coordinate work towards that outcome. People who are good at owning things will push most decisions to people closer to each sub-problem, while giving an overall framework that keeps everyone rowing in the same direction. For Product, that manifests as a roadmap with high level prioritization, but plenty of room for engineers to tweak scope or ordering to take on targets of opportunity.
I really can't stress how unpleasant working in the world you describes sounds to me, as a developer. Through my career, so much work could have been avoided or improved if developers were in more discovery meetings, messing around in Figma, etc.
Senior people should be expected to bring an engineer's perspective to these tasks, and mentor junior engineers in the process to bring them up to that level.
Senior people should be expected to bring an engineer's perspective to these tasks, and mentor junior engineers in the process to bring them up to that level.
> Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.
This is so good and yet so painful.
This is so good and yet so painful.
> Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.
This doesn't add anything to the rest of the comment, does it? It insults the developers with the implication that they think they're so good when they aren't. When the problem being discussed has nothing to do with how good they are in the first place.
This doesn't add anything to the rest of the comment, does it? It insults the developers with the implication that they think they're so good when they aren't. When the problem being discussed has nothing to do with how good they are in the first place.
To me it doesn’t seem to speak at all to “how good” anybody is, just to the nature of the work the job demands.
A fine artist will paint a better portrait, but they might not be the right hire to get a housing development painted and shipped (so to speak).
The fine artist may be less good at house painting than the tradesman, the tradesman may be less good at portraiture than the fine artist.
There’s always the possibility that somebody could be good at both, but they’re orthogonal: both dip something in paint, but that’s where the similarities end.
A fine artist will paint a better portrait, but they might not be the right hire to get a housing development painted and shipped (so to speak).
The fine artist may be less good at house painting than the tradesman, the tradesman may be less good at portraiture than the fine artist.
There’s always the possibility that somebody could be good at both, but they’re orthogonal: both dip something in paint, but that’s where the similarities end.
It's pretty dismissive to suggest that any form of software development is anywhere near as mindless as painting walls white endlessly
Software has decision making constantly, even at junior levels
Whitewashing walls has more or less no decisions other than what room to start in
Software has decision making constantly, even at junior levels
Whitewashing walls has more or less no decisions other than what room to start in
It’s pretty dismissive of painters to say it requires no decisions.
Painting requires a lot of decisions, from the coverage, speed of drying, (for additional layers) protecting the environment, ensuring equal coverage (paint guns are harder than they look for quality and consistent coverage).
Cut in near non-painted features is a whole thing as well.
But sure, let’s dismiss an entire trade because SWE is so special.
Painting requires a lot of decisions, from the coverage, speed of drying, (for additional layers) protecting the environment, ensuring equal coverage (paint guns are harder than they look for quality and consistent coverage).
Cut in near non-painted features is a whole thing as well.
But sure, let’s dismiss an entire trade because SWE is so special.
Painting as a trade can absolutely be more complex
But what the OP said about "take this sprayer and make those walls white" is not
Don't conflate the two
But what the OP said about "take this sprayer and make those walls white" is not
Don't conflate the two
Oh man. I felt that way before I jumped into drywall work in a family member’s house—it’s making something white, how hard could it be? MAN did my repair job come out streaky and cracked. And it took me about 2 weeks to get through one wall and a ceiling. Poorly.
I feel that way when I show up at corporate software shops too—think cubicle farms toiling at the coalface of some massive ancient line-of-business application. I would not survive there. And the company needs people who would thrive there, instead of me.
I feel that way when I show up at corporate software shops too—think cubicle farms toiling at the coalface of some massive ancient line-of-business application. I would not survive there. And the company needs people who would thrive there, instead of me.
[deleted]
It’s not insulting. Engineers are smart and like to solve wickedly difficult problems. But sometimes that’s not what’s needed.
Let’s say I need a web form that puts user inputs into a database. Picasso goes to a cabin in the woods for two weeks to architect something that handles every edge case and is absolutely elegant. House painter knocks out something acceptable in an afternoon and works on something for paying customers the rest of time. There’s a time and place for both, but a lot of software development honestly just needs painters.
Let’s say I need a web form that puts user inputs into a database. Picasso goes to a cabin in the woods for two weeks to architect something that handles every edge case and is absolutely elegant. House painter knocks out something acceptable in an afternoon and works on something for paying customers the rest of time. There’s a time and place for both, but a lot of software development honestly just needs painters.
> It’s not insulting... but a lot of software development honestly just needs painters.
The entire Picasso vs house painter analogy is insulting.
> Picasso goes to a cabin in the woods for two weeks to architect something that handles every edge case and is absolutely elegant...
If this is a product owner's idea of how software development occurs, they must be either clueless, narcissistic, cruel, or all of the above.
The entire Picasso vs house painter analogy is insulting.
> Picasso goes to a cabin in the woods for two weeks to architect something that handles every edge case and is absolutely elegant...
If this is a product owner's idea of how software development occurs, they must be either clueless, narcissistic, cruel, or all of the above.
> Ideally, I want engineers focused on building, not taking discovery meetings with potential customers, messing around in Figma, projecting financials, writing ads, or any other role
This is a very short-sighted view and one of the reasons a lot of engineers hate their jobs today - even though they might say they “just want to code”.
Software engineering is ultimately about building things for people (or machines), so the more distance you put between the engineering and the end goal, the worse outcome you get. You can definitely have specialized functions like marketing, copy-writing, design, but they all work together in a multi-disciplinary team, understand what they are building and why so that they have shared knowledge and goals.
On that strawman argument, nobody expects developers to routinely do client meetings or financial projections, though they should be able to delve into that if it will help build a better product. To continue your analogy, in great kitchens everyone knows the dishes they are making, the whole menu, get to taste it, and can probably take any other station if required.
This is a very short-sighted view and one of the reasons a lot of engineers hate their jobs today - even though they might say they “just want to code”.
Software engineering is ultimately about building things for people (or machines), so the more distance you put between the engineering and the end goal, the worse outcome you get. You can definitely have specialized functions like marketing, copy-writing, design, but they all work together in a multi-disciplinary team, understand what they are building and why so that they have shared knowledge and goals.
On that strawman argument, nobody expects developers to routinely do client meetings or financial projections, though they should be able to delve into that if it will help build a better product. To continue your analogy, in great kitchens everyone knows the dishes they are making, the whole menu, get to taste it, and can probably take any other station if required.
One of the things that attracted me to SAFe (I know, a lot of folks have had bad experiences, hear me out) was the dual backlog. Most places I know where SAFe went sideways did not use this and IMO it's one of the key selling points to the whole system.
Essentially, there's the Program Backlog which is managed by Product and the rest of the business. And the Solution Backlog, which is managed and prioritized entirely by the tech teams. Going into a PI, the goal is to allocate capacity to both and typically that is a 70-30 balance but it ensure that the teams can prioritize anything they believe is important without having to bother convincing the non-technical side of the company.
https://v5.scaledagileframework.com/program-and-solution-bac...
Unfortunately where Scrum, SAFe and most other things go wrong is not the system itself. It's leadership trying to enforce a command and control structure to remove decision making from people closest to the problems.
Essentially, there's the Program Backlog which is managed by Product and the rest of the business. And the Solution Backlog, which is managed and prioritized entirely by the tech teams. Going into a PI, the goal is to allocate capacity to both and typically that is a 70-30 balance but it ensure that the teams can prioritize anything they believe is important without having to bother convincing the non-technical side of the company.
https://v5.scaledagileframework.com/program-and-solution-bac...
Unfortunately where Scrum, SAFe and most other things go wrong is not the system itself. It's leadership trying to enforce a command and control structure to remove decision making from people closest to the problems.
I think this comment should be framed as a solid example of why you shouldn't have non-tech people manage tech teams. Feudal mindset that doesn't represent development outside of bottom tier tech companies.
Then again... engineers like to think themselves Super Smart(tm) yet forget who's paid to do all the fun sidequests while ya'll stuck "chopping onions" for those 'dumb' Product Lords.
Then again... engineers like to think themselves Super Smart(tm) yet forget who's paid to do all the fun sidequests while ya'll stuck "chopping onions" for those 'dumb' Product Lords.
> Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.
Oh, so the product owner is Picasso here and the software engineers a bunch of painters? What a load of condescending bullshit!
> In the kitchen analogy, we need cooks to do boring stuff like chop 100 onions and make dinner rolls.
And programming is the boring stuff in this analogy? This is why the software engineers think that product owners, scrum masters, and the like are bunch of idiots, who don't know what they are talking about.
And why should engineers not mess with Figma? The designers and product owners, in all their creative wisdom, ask for unimplementable, inaccessible, unnecessarily time consuming BS all the time without any understanding of what goes in software design, architecture, and implementation. Then they complain about missed deadlines, blown budgets, etc. And then we end up with stupid stuff like Scrum because engineers can't be trusted to self-organize their development process. Perhaps product owners should come off from their high horse and learn to be proper team members?
Oh, so the product owner is Picasso here and the software engineers a bunch of painters? What a load of condescending bullshit!
> In the kitchen analogy, we need cooks to do boring stuff like chop 100 onions and make dinner rolls.
And programming is the boring stuff in this analogy? This is why the software engineers think that product owners, scrum masters, and the like are bunch of idiots, who don't know what they are talking about.
And why should engineers not mess with Figma? The designers and product owners, in all their creative wisdom, ask for unimplementable, inaccessible, unnecessarily time consuming BS all the time without any understanding of what goes in software design, architecture, and implementation. Then they complain about missed deadlines, blown budgets, etc. And then we end up with stupid stuff like Scrum because engineers can't be trusted to self-organize their development process. Perhaps product owners should come off from their high horse and learn to be proper team members?
> An apt analogy for the proper relationship between product and engineering is a restaurant.
> Engineers are the chefs in the back...
I can't help but feel that this betrays a misunderstanding of both Product work and restaurant kitchens. As I see it, while in some restaurants everyone may be called "chef", there is only one "Chef" (with a capital C) who is really in charge of the menu. While everyone benefits from being informed and their input should be respected, if everyone in the kitchen were to make independent menu decisions, it would be anarchy. Same with tech projects, there is a strong benefit to having a singular vision of "what" we are about to release - and the inverse, to avoid scope creep.
I have seen cases where a power-hungry incompetent product owner sets up "mushroom management", but I don't see how having everyone constantly making their own independent product decisions would make things better. As another comment here said, product owners should have authority of the what, while offering engineers and designers information and full flexibility on the how.
To bring it back to the author's analogy - "Too many cooks spoil the broth".
EDIT: minor copy-editing
> Engineers are the chefs in the back...
I can't help but feel that this betrays a misunderstanding of both Product work and restaurant kitchens. As I see it, while in some restaurants everyone may be called "chef", there is only one "Chef" (with a capital C) who is really in charge of the menu. While everyone benefits from being informed and their input should be respected, if everyone in the kitchen were to make independent menu decisions, it would be anarchy. Same with tech projects, there is a strong benefit to having a singular vision of "what" we are about to release - and the inverse, to avoid scope creep.
I have seen cases where a power-hungry incompetent product owner sets up "mushroom management", but I don't see how having everyone constantly making their own independent product decisions would make things better. As another comment here said, product owners should have authority of the what, while offering engineers and designers information and full flexibility on the how.
To bring it back to the author's analogy - "Too many cooks spoil the broth".
EDIT: minor copy-editing
The difference in the kitchen analogy is the Chef comes from a background in cooking food and was once a kitchen cook. Many in product are completely non technical. In this case the kitchen cooks and minor chefs will be told to cook dishes out of season, and do impractical things. I view product and engineering as a complementary resource not one directing the other what to do. Often times "what" is dictated by "how" in software development
> if everyone in the kitchen were to make independent menu decisions, it would be anarchy
If a committee of chefs were to make menu decisions, it would be anarchy.
If a committee of chefs were to make menu decisions, it would be anarchy.
Please don't confuse anarchy with chaos.
Please don’t impose your solely political definition on others; anarchy meaning disorder (i.e. chaos) is a well attested meaning of the term.
> anarchy: absence of order : DISORDER
https://www.merriam-webster.com/dictionary/anarchy
> anarchy: Confusion in general; disorder.
https://en.wiktionary.org/wiki/anarchy
> anarchy: confusion and disorder
https://www.dictionary.com/browse/anarchy
> anarchy: absence of order : DISORDER
https://www.merriam-webster.com/dictionary/anarchy
> anarchy: Confusion in general; disorder.
https://en.wiktionary.org/wiki/anarchy
> anarchy: confusion and disorder
https://www.dictionary.com/browse/anarchy
Anarchy in this case seems like a good choice of word to me, at least. No single leader, no single direction.
I find it strange that businesses in America shed that efficiency.
To me, this recurring narrative of product versus engineering is both tiresome and misguided.
In well-run companies, commercial, product, and engineering teams are aligned - overused as the term may be. Any misalignment points to fundamental flaws in company culture. In my experience, this misalignment is what causes so much pain in high-growth companies that introduce managerial roles to a previously founder-led culture - not the product owner role as such.
It's counterproductive to stereotype POs as overbearing taskmasters, or to cast engineers as creators of beautiful but useless code. Such perceptions, if prevalent within a company, should be the primary issue to address. There's certainly features that POs don't enjoy working on but they have to - same for engineers (think about all those compliance features).
I believe POs can serve as a vital bridge between commercial and engineering departments. They clarify how features add customer value, explain business objectives behind projects and help decide what's next on the roadmap. Additionally, they help maintain focus by minimising abrupt directional shifts in the roadmap that could waste resources. And they can weigh in on decisions when they see that engineering teams are already strained by other projects or any business-as-usual work.
In that way, everyone is be enabled to do their best work and the PO is not reduced to the cookie cutter version the author portrays in the article.
In well-run companies, commercial, product, and engineering teams are aligned - overused as the term may be. Any misalignment points to fundamental flaws in company culture. In my experience, this misalignment is what causes so much pain in high-growth companies that introduce managerial roles to a previously founder-led culture - not the product owner role as such.
It's counterproductive to stereotype POs as overbearing taskmasters, or to cast engineers as creators of beautiful but useless code. Such perceptions, if prevalent within a company, should be the primary issue to address. There's certainly features that POs don't enjoy working on but they have to - same for engineers (think about all those compliance features).
I believe POs can serve as a vital bridge between commercial and engineering departments. They clarify how features add customer value, explain business objectives behind projects and help decide what's next on the roadmap. Additionally, they help maintain focus by minimising abrupt directional shifts in the roadmap that could waste resources. And they can weigh in on decisions when they see that engineering teams are already strained by other projects or any business-as-usual work.
In that way, everyone is be enabled to do their best work and the PO is not reduced to the cookie cutter version the author portrays in the article.
I think this is a valid approach, but success is contingent on working with product-minded engineers [0]. I consider myself to be one, so I'm a fan of this approach. There are also many engineers who aren't product-minded, and they might prefer working in a culture where their job is to focus on execution.
[0] https://blog.pragmaticengineer.com/the-product-minded-engine...
[0] https://blog.pragmaticengineer.com/the-product-minded-engine...
Agreed. In that situation (following tfa's language) the product owner must either be an architect or be besties with one. A hoard of relatively unskilled laborers is not going to produce a cogent product otherwise. Then, what are you left with? The architect is leading the charge.
It's also good to take a step back and recall that all of these prescriptive, brand-name models for making software are, in fact, products in and of themselves. Their purported aim is to improve software, but what they really do is sell books, conference tickets, and consulting services.
It's also good to take a step back and recall that all of these prescriptive, brand-name models for making software are, in fact, products in and of themselves. Their purported aim is to improve software, but what they really do is sell books, conference tickets, and consulting services.
Former PM/PO and my best experiences were when the engineers had final authority on how it works, but I had final say on what it does
SWE here with experience on product development through a few startups earlier in my life, working on larger orgs later.
I wouldn't choose any other way. As a SWE I can have my opinions about the product, I can build a business case for what I see might be gaps in the offering and try to sell it but I'd still very much need the PO/PM to take the job of fleshing that out to users'/product's needs and defining the "what" better than I can.
A well-oiled product team is invaluable, there's very few things I hate more in this career than working with an incompetent product manager, everyone else's lives become extremely difficult if a PM is not doing a good job.
I wouldn't choose any other way. As a SWE I can have my opinions about the product, I can build a business case for what I see might be gaps in the offering and try to sell it but I'd still very much need the PO/PM to take the job of fleshing that out to users'/product's needs and defining the "what" better than I can.
A well-oiled product team is invaluable, there's very few things I hate more in this career than working with an incompetent product manager, everyone else's lives become extremely difficult if a PM is not doing a good job.
I don't think it would make sense any other way. When doing rituals like refinement and sprint planning, POs want features but have no idea how they interact with what's already there, or how integrations are implemented, or how things are optimized. Simple features might be very complex to change for example, often because product itself asked to make something that does not scale for the sake of velocity, and now wants to build on top of that.
There should be a conversation, engineers should inform POs about risks, alternatives, workarounds, etc. Sometimes POs are just not aware that there is a much better way to do X.
There should be a conversation, engineers should inform POs about risks, alternatives, workarounds, etc. Sometimes POs are just not aware that there is a much better way to do X.
[deleted]
The central premise of the article seems to me to be a likely misunderstanding of the problem. I would bet that a Scrum Product Owner who uses a "command and control" leadership style and doesn't know how to properly delegate authority would be doing the same under any other development framework, too.
In general I'm a big fan of the "single wringable neck" principle. I've seen it put to great effect in the hands of a skilled leader, in both Scrum and non-Scrum teams. Better yet, when the leader isn't managing things well, it also leaves no question that they're the one who needs to figure out how to set things straight. Same goes for their delegates.
And for the ICs it makes collaboration easier - and therefore, ironically, enables them to work more autonomously. When everyone unambiguously knows what they're in charge of and what the team's big-picture objectives are, they have everything they need to independently figure out how best to make it happen. And it's also a lot easier to figure out who to talk to when they need to call attention to a problem.
I've seen a lot less luck with shared authority and informal delegation. On the best of days, it turns decisionmaking into an unnecessarily political process. More likely, the team will settle into an informal consensus process that typically operates as "rule by the obdurate" in practice. And when things get tough, the leaders will tend to slide into unproductive bickering that all but precludes actually fixing the problem.
Favorite readings that touch on this kind of thing: The Tyranny of Structurelessness by Jo Freeman, and Turn the Ship Around! by David Marquet.
In general I'm a big fan of the "single wringable neck" principle. I've seen it put to great effect in the hands of a skilled leader, in both Scrum and non-Scrum teams. Better yet, when the leader isn't managing things well, it also leaves no question that they're the one who needs to figure out how to set things straight. Same goes for their delegates.
And for the ICs it makes collaboration easier - and therefore, ironically, enables them to work more autonomously. When everyone unambiguously knows what they're in charge of and what the team's big-picture objectives are, they have everything they need to independently figure out how best to make it happen. And it's also a lot easier to figure out who to talk to when they need to call attention to a problem.
I've seen a lot less luck with shared authority and informal delegation. On the best of days, it turns decisionmaking into an unnecessarily political process. More likely, the team will settle into an informal consensus process that typically operates as "rule by the obdurate" in practice. And when things get tough, the leaders will tend to slide into unproductive bickering that all but precludes actually fixing the problem.
Favorite readings that touch on this kind of thing: The Tyranny of Structurelessness by Jo Freeman, and Turn the Ship Around! by David Marquet.
I used Scrum with my teams for about 1.5 year, and tried hard to adjust the framework. Then we switched to Kanban, which matches much better the realities of an innovative and B2B product.
The main benefit of scrum is that it forces stakeholders to discuss goals and priorities.
But the framework itself has flaws in its philosophy. The Scrum book is adamant that the results of a sprint should be a user facing change, which doesn't always aligned with the "path of most value generated" that an organization should follow. For instance my team is working right now on transitioning our data storage system to a different offering in Azure as the type of PostgreSQL service we use is being retired. That's a non user facing but imperative change. Similarly, as our products are getting mature we work on both incremental improvements and longer term (6-12 months) ML/AI projects which are discussed with our clients. Our product manager has to be involved with those too and sometimes prioritize engineering work related to them. Scrum simply ignore this reality of operational tasks, and medium/long term value generation
The main benefit of scrum is that it forces stakeholders to discuss goals and priorities.
But the framework itself has flaws in its philosophy. The Scrum book is adamant that the results of a sprint should be a user facing change, which doesn't always aligned with the "path of most value generated" that an organization should follow. For instance my team is working right now on transitioning our data storage system to a different offering in Azure as the type of PostgreSQL service we use is being retired. That's a non user facing but imperative change. Similarly, as our products are getting mature we work on both incremental improvements and longer term (6-12 months) ML/AI projects which are discussed with our clients. Our product manager has to be involved with those too and sometimes prioritize engineering work related to them. Scrum simply ignore this reality of operational tasks, and medium/long term value generation
I'd say Scrum is more about creating business value than user facing change. It is the business that consistently doesn't value long term value generation, not the process.
Yes, the goal is to generate business value. But Scrum requires to do this in small increments, and these increments have to be exposed to stakeholders. As per the Scrum guide (https://scrumguides.org/scrum-guide.html#increment):
"In order to provide value, the Increment must be usable."
So this conflicts with the fact that business value can be generated (or protected, in the case of maintenance/upgrade of a system) without generating immediately "usable" changes. Or said otherwise, a high value change may requires a succession of non-usable changes over many "sprints", and Scrum doesn't account for that.
"In order to provide value, the Increment must be usable."
So this conflicts with the fact that business value can be generated (or protected, in the case of maintenance/upgrade of a system) without generating immediately "usable" changes. Or said otherwise, a high value change may requires a succession of non-usable changes over many "sprints", and Scrum doesn't account for that.
I agree with a lot of this, but disagree with the final conclusion that Product shouldn't define what is going to be built. Everything listed in TFA is something a good PM and a product-minded engineer collaborate and iterate on. At the end of the day, I think the article is really concluding that "bad Product Managers shouldn't define what is built."
The actual issue with Scrum is that APMs and others who identify as "Product Owners" often aren't trained or equipped to be good at actual product management, because they are focused on a fake set of JIRA-focused responsibilities. A "Product Owner" is really a software development project manager who uses a ticketing system to micro-manage engineering work.
The result is that scrum POs are bad Product Managers. Their role has little to do with understanding user needs, establishing and communicating a vision of a product's philosophy, or assessing the success of a feature once it's out in customer hands.
Scrum ends up wrong on two fronts:
* It has no idea how work is prioritized (much of the actual work of product management), and
* It thinks that "priorities" are a well-ordered list of discrete development tasks rather than features, and assigns much of the engineer's role to the PO.
It's as if Scrum defined a new role called "chief financial owner" who is responsible for making sure the columns are aligned in the annual financial statements, and then the job market was flooded with thousands of people with two years of experience saying "I'm a CFO" and we got hundreds of think pieces about why all these companies were having trouble managing cash.
The actual issue with Scrum is that APMs and others who identify as "Product Owners" often aren't trained or equipped to be good at actual product management, because they are focused on a fake set of JIRA-focused responsibilities. A "Product Owner" is really a software development project manager who uses a ticketing system to micro-manage engineering work.
The result is that scrum POs are bad Product Managers. Their role has little to do with understanding user needs, establishing and communicating a vision of a product's philosophy, or assessing the success of a feature once it's out in customer hands.
Scrum ends up wrong on two fronts:
* It has no idea how work is prioritized (much of the actual work of product management), and
* It thinks that "priorities" are a well-ordered list of discrete development tasks rather than features, and assigns much of the engineer's role to the PO.
It's as if Scrum defined a new role called "chief financial owner" who is responsible for making sure the columns are aligned in the annual financial statements, and then the job market was flooded with thousands of people with two years of experience saying "I'm a CFO" and we got hundreds of think pieces about why all these companies were having trouble managing cash.
The product role is far too broad. It's absurd. The more experience I get in both product and engineering leads me to believe that product should be a scout out ahead of the team, identifying the most valuable things to build. Product people should spend more time with customers and internal stakeholders. Implementation below the epic level should be handled by the engineering team.
https://docs.google.com/drawings/d/1-6iUUbfFp3UFK24_OymF7ciX...
https://docs.google.com/drawings/d/1-6iUUbfFp3UFK24_OymF7ciX...
As far as I can tell, almost nobody, whether engineers, product owners, sales people, or sometimes even executives, has a firm grasp on how a company creates value for its customers. Sometimes this is because the company destroys value instead and everybody’s trying not to know it. But even at productive companies that should be proud of their products and services, most people can’t explain how the business works.
This is bad. If you know why you’re making money, it’s a lot easier to make the right decision.
This is bad. If you know why you’re making money, it’s a lot easier to make the right decision.
That's probably only true for most coffee bean subscription SaaS startups, but the world is full of pretty normal business, in which pretty standard engineers and other professionals work, that make money in a streamlined and predictable way but who's story doesn't make it to HN unfortunately.
I wish that were the case. I’ve spent a good chunk of my career in the “Real Engineer” widget making world, and it’s that experience I’m speaking of here. Even in the semiconductor industry, most people just kept their heads down and never connected their work to the customer, never even thought about what kind of device the chips were going into.
Maybe it's just that everyone is too fixated on "creating value for customers", might it be that customers don't really want value, but they just want to buy stuff? This might explain this big divergence in our real world experiences. It's either this or that most businesses actually do bring some value and have a degree of understanding of what they're doing, otherwise no customer would be buying anything and unemployment rate would be closer to 99% everywhere.
[deleted]
The article opens with:
> In Scrum, Product Owners have sole authority over the Product Backlog; they control what to build and when to build it. Engineers are merely ticket-takers, implementing one instruction after another.
I think this immediately starts the article off in the wrong place. An Engineer that is a "ticket-taker" is relegating themselves to that role; they have more agency than that.
If you're able to cogently explain why something needs to done, and are additionally weighing product value while doing that, you will be heard. Stakeholders are not the problem here.
> In Scrum, Product Owners have sole authority over the Product Backlog; they control what to build and when to build it. Engineers are merely ticket-takers, implementing one instruction after another.
I think this immediately starts the article off in the wrong place. An Engineer that is a "ticket-taker" is relegating themselves to that role; they have more agency than that.
If you're able to cogently explain why something needs to done, and are additionally weighing product value while doing that, you will be heard. Stakeholders are not the problem here.
The respected and socially competent engineer should always fulfill the traditional PO obligations. I believe the buzzword for this is Product Engineer, even though that’s roughly what agile was supposed to be to begin with…
The problem with this is somewhat real though and it’s that companies do not prioritize this capability set over the “traditional” ones where the engineer never has to talk to a customer. Given that anyone that codes is at least probably lightly on the Autism spectrum, and you end up with only a subset that can successfully do both roles.
The problem with this is somewhat real though and it’s that companies do not prioritize this capability set over the “traditional” ones where the engineer never has to talk to a customer. Given that anyone that codes is at least probably lightly on the Autism spectrum, and you end up with only a subset that can successfully do both roles.
> The respected and socially competent engineer should always fulfill the traditional PO obligations
This is sort of the problem isn't it? You have a significant portion of people in business who believe that engineers are not socially competent by nature, and another significant portion that simply does not respect engineers in the slightest, instead treating them like an assembly line
There's probably a large overlap between the two groups, but it's not a circular venn diagram
I can't be the only person who has encountered dismissive comments from departments outside of R&D, or from managers higher up the food chain, about engineers ability or value
I mean a lot of companies treat engineers as fungible assets, as if the only value we provide is slinging code and any engineer could do that
This is sort of the problem isn't it? You have a significant portion of people in business who believe that engineers are not socially competent by nature, and another significant portion that simply does not respect engineers in the slightest, instead treating them like an assembly line
There's probably a large overlap between the two groups, but it's not a circular venn diagram
I can't be the only person who has encountered dismissive comments from departments outside of R&D, or from managers higher up the food chain, about engineers ability or value
I mean a lot of companies treat engineers as fungible assets, as if the only value we provide is slinging code and any engineer could do that
> Given that anyone that codes is at least probably lightly on the Autism spectrum
What?!
What?!
Often there is not so much work for PO as many projects are not dealing with something new but a slight variation of existing functionality. In contrast to this just reinventing the wheel on a newer stack requires many architectural, tactical and technical decisions. The role of the architect has been relegated to ‚the team‘ and is parceled into user stories chopped into sprints. Without balancing mechanisms for product and technical leadership we will continue to produce random quality under consistent high pain.
This is atrocious advice. It's basically "give the product managing responsibility to engineers". The PM in this scenario is basically relegated to the "I have people skills!" role from Office Space.
I think Pivotal nailed this one:
* PM's don't code. The job of the PM is to look at the product from the customer perspective and direct the team to change the product in a way that delivers business value.
* Chores (refactorings, architecture changes, etc; any story that isn't visible to a csutomer) aren't pointed. Engineers can put them in the backlog and work on them, but it will slow down velocity. That's the system working as intended.
The problem with engineers dominating the PM is that engineers will be tempted to pick features that they enjoy working on, not necessarily what moves the business needle. Can engineers do PM work, especially on small teams with highly technical products? Of course, and the best engineers are product-minded. But understanding the customer is a full time job.
I think a lot of HN is poisoned by working on products for other techies, like databases and development tools. Most software in the wild runs lines of business. Tell me how your engineers are going to PM a medical billing system, or a financial planner, or the DMV website. It's not impossible - but the talented developer who already has domain knowledge is elusive and you can't afford them anyway.
I think Pivotal nailed this one:
* PM's don't code. The job of the PM is to look at the product from the customer perspective and direct the team to change the product in a way that delivers business value.
* Chores (refactorings, architecture changes, etc; any story that isn't visible to a csutomer) aren't pointed. Engineers can put them in the backlog and work on them, but it will slow down velocity. That's the system working as intended.
The problem with engineers dominating the PM is that engineers will be tempted to pick features that they enjoy working on, not necessarily what moves the business needle. Can engineers do PM work, especially on small teams with highly technical products? Of course, and the best engineers are product-minded. But understanding the customer is a full time job.
I think a lot of HN is poisoned by working on products for other techies, like databases and development tools. Most software in the wild runs lines of business. Tell me how your engineers are going to PM a medical billing system, or a financial planner, or the DMV website. It's not impossible - but the talented developer who already has domain knowledge is elusive and you can't afford them anyway.
> It's basically "give the product managing responsibility to engineers".
It's really not going that far. It is critical of the notion that someone without software engineering chops can dictate an appropriate ordering of sub-jobs. That's a legitimate position to take, and we observe it in practice regularly.
It's also in a very specific context, Scrum, and it's talking about these rigidly defined roles. It doesn't really make sense to discuss it outside of this context, because Scrum puts itself in a precarious position. The #1 rule of Scrum, literally, is "A Product Owner orders the work for a complex problem into a Product Backlog." This is what the author is going after. And, there can be no absolutely no deviation, because "The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum."
It's really not going that far. It is critical of the notion that someone without software engineering chops can dictate an appropriate ordering of sub-jobs. That's a legitimate position to take, and we observe it in practice regularly.
It's also in a very specific context, Scrum, and it's talking about these rigidly defined roles. It doesn't really make sense to discuss it outside of this context, because Scrum puts itself in a precarious position. The #1 rule of Scrum, literally, is "A Product Owner orders the work for a complex problem into a Product Backlog." This is what the author is going after. And, there can be no absolutely no deviation, because "The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum."
That sounds fine? The Pivotal process is equally rigid about the backlog order.
But the important distinction - and if you've never worked with a Pivotal team you might not realize it - is that the pointed stories in the backlog are all customer-facing. They represent business priorities. The PM absolutely defines the business priorities.
Pointed stories are not created in a vacuum; the PM works with the tech leads to define reasonable features. And pointing is done by the engineers.
Also, nothing stops the eng team from adding (unpointed) chores to the backlog and working on them! But there's a velocity cost and that can affect delivery dates. There's negotiation involved.
If the PM is micromanaging engineering tasks, you're doing it wrong. The process requires a good PM.
But the important distinction - and if you've never worked with a Pivotal team you might not realize it - is that the pointed stories in the backlog are all customer-facing. They represent business priorities. The PM absolutely defines the business priorities.
Pointed stories are not created in a vacuum; the PM works with the tech leads to define reasonable features. And pointing is done by the engineers.
Also, nothing stops the eng team from adding (unpointed) chores to the backlog and working on them! But there's a velocity cost and that can affect delivery dates. There's negotiation involved.
If the PM is micromanaging engineering tasks, you're doing it wrong. The process requires a good PM.
Thr current Scrum guide also defines two separate backlogs: sprint and product.
> It is critical of the notion that someone without software engineering chops can dictate an appropriate ordering of sub-jobs
This is the exact issue. And people talk past it all the time.
Product designs the specs for a set of changes & proposes a timeline. Engineering breaks that down, perhaps the two sides negotiate on the timeline. Beyond that, Product should generally stay out of the day to day. "I want sub-sub-sub-widget-X first" discussions are what lead to the tension that we see here.
This is the exact issue. And people talk past it all the time.
Product designs the specs for a set of changes & proposes a timeline. Engineering breaks that down, perhaps the two sides negotiate on the timeline. Beyond that, Product should generally stay out of the day to day. "I want sub-sub-sub-widget-X first" discussions are what lead to the tension that we see here.
I have worked with so-called “product minded” engineers who 1) do nothing, 2) do what they want, or 3) try to tell product how to do their job. It is dysfunction at its finest.
I'm struggling with this a bit. At a certain point it feels you get pushed in this direction. So many other non-engineers have ideas/promises... and being the one who provides the eggs, incentives are not great.
For those curious about the Pivotal Labs product innovation process, check out this guide. In my opinion, it's the best end-to-end guide on how it all works together.
It's a product of 20+ years of iteration & weekly retrospectives - and was used to coach clients on how to collaborate as a team and build high quality products. Definitely download it, and review from time to time - many gold nuggets.
https://tanzu.vmware.com/content/white-papers/vmware-tanzu-l...
(Used to work at Pivotal)
It's a product of 20+ years of iteration & weekly retrospectives - and was used to coach clients on how to collaborate as a team and build high quality products. Definitely download it, and review from time to time - many gold nuggets.
https://tanzu.vmware.com/content/white-papers/vmware-tanzu-l...
(Used to work at Pivotal)
I was expecting it to address the common practice of product owners often not owning business outcomes.
Also would have loved to see mention of the hijinks that goes on around half-ass features often in conjunction with the abuse of the term MVP.
Also would have loved to see mention of the hijinks that goes on around half-ass features often in conjunction with the abuse of the term MVP.
> The Scrum Guide would have you believe there are only two appropriate questions to ask a Product Owner
A lot of people over-interpret rigid hierarchy’s, when Scrum is supposed to be the opposite.
From the actual scrum guide: https://scrumguides.org/scrum-guide.html
> The Product Owner is also accountable for effective Product Backlog management… The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
It’s entirely compatible with Scrum for the engineers to sit with customers and come up with backlog items, and the PO to take the role of ensuring backlog quality and reviewing strategic direction of the work items being added by developers.
A lot of people over-interpret rigid hierarchy’s, when Scrum is supposed to be the opposite.
From the actual scrum guide: https://scrumguides.org/scrum-guide.html
> The Product Owner is also accountable for effective Product Backlog management… The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
It’s entirely compatible with Scrum for the engineers to sit with customers and come up with backlog items, and the PO to take the role of ensuring backlog quality and reviewing strategic direction of the work items being added by developers.
Exactly. This article starts with a misunderstanding:
> In Scrum, Product Owners have sole authority over the Product Backlog
While, as per your quote (emphasis mine)
> The Product Owner is also _accountable_ for effective Product Backlog management… The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains _accountable_.
Meaning they have the final say, not that they decide on their own without any input from the team.
My impression is that OP just had to work with bad POs who didn't understand their role.
> In Scrum, Product Owners have sole authority over the Product Backlog
While, as per your quote (emphasis mine)
> The Product Owner is also _accountable_ for effective Product Backlog management… The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains _accountable_.
Meaning they have the final say, not that they decide on their own without any input from the team.
My impression is that OP just had to work with bad POs who didn't understand their role.
This is actually really simple to solve: product articulates the problem, engineering designs the solution.
When product tries to design the solution, tosses it over the fence, and engineers who don't know any better just implement it, you end up with a codebase that consists of parts duct-taped onto the side of other parts. Over time this compounds the cost of future development.
When you let engineering design the solution, they design for reuse, with the lightest touch. This decreases the cost of future development by keeping the codebase maintainable, understandable, unsurprising, simple, etc.
If your user stories from product contain implementation details, you need to guide the discussion back to the actual problem that needs to be solved.
When product tries to design the solution, tosses it over the fence, and engineers who don't know any better just implement it, you end up with a codebase that consists of parts duct-taped onto the side of other parts. Over time this compounds the cost of future development.
When you let engineering design the solution, they design for reuse, with the lightest touch. This decreases the cost of future development by keeping the codebase maintainable, understandable, unsurprising, simple, etc.
If your user stories from product contain implementation details, you need to guide the discussion back to the actual problem that needs to be solved.
Not only is this easy to solve, Scrum is one solution. Like this is the core of what it attempts to solve.
The same essential skills make a great PO/business analyst as a great engineer: the ability to think in abstract terms and the ability to debug.
When successful POs write a book or something, they present the best-practices. They don't share the most important wisdom though: there are pretty smart to start with... Applying their practices without the ability to think does not work, and it's not something one can pick up on the go.
Nothing comes from nothing.
When successful POs write a book or something, they present the best-practices. They don't share the most important wisdom though: there are pretty smart to start with... Applying their practices without the ability to think does not work, and it's not something one can pick up on the go.
Nothing comes from nothing.
This is not a Product Owner problem, nor a Scrum problem. Get ready for some No True Scotsmanning:
The product backlog is a collection of User Stories. The user story describes a problem and starts out as a placeholder for a discussion in the team to figure out what the problem is and how we can solve it.
The Product Owner prioritizes these problems against eachother. The team members can communicate. Talking is not forbidden, in fact it is encouraged.
The product backlog is a collection of User Stories. The user story describes a problem and starts out as a placeholder for a discussion in the team to figure out what the problem is and how we can solve it.
The Product Owner prioritizes these problems against eachother. The team members can communicate. Talking is not forbidden, in fact it is encouraged.
Right off the bat I can see where they are going astray.
> In Scrum, Product Owners have sole authority over the Product Backlog; they control what to build and when to build it.
True, POs have authority over the Product Backlog. Guess what they don't have authority over? The Sprint Backlog - you know, where things actually get made, not just talked about. A PO actually has zero _authority_ over the Scrum team at all.
> In Scrum, Product Owners have sole authority over the Product Backlog; they control what to build and when to build it.
True, POs have authority over the Product Backlog. Guess what they don't have authority over? The Sprint Backlog - you know, where things actually get made, not just talked about. A PO actually has zero _authority_ over the Scrum team at all.
Whenever you see one of these "it's product" or "it's engineers" all I can think of is "someone has more business context or knowledge than the others"
The best teams I've ever worked on as a product manager/owner is where we have shared context. These problems described here are minimal. In those teams I could provide technical input to engineers, and engineers gave me "consumer facing" suggestions on features.
I've believed for a long time that lack of business/use context drives a lot of these issues.
Take for instance I currently work at an IoT company, and if I'm working with engineers who have no idea what a thermostat does/how it works other than "makes it hotter or colder" then we have much more difficulty building shared understanding of a feature request.
I also know this because 10 years ago that was my simple understanding of a thermostat... so it was much harder for me to understand why we were doing certain things.
The best teams I've ever worked on as a product manager/owner is where we have shared context. These problems described here are minimal. In those teams I could provide technical input to engineers, and engineers gave me "consumer facing" suggestions on features.
I've believed for a long time that lack of business/use context drives a lot of these issues.
Take for instance I currently work at an IoT company, and if I'm working with engineers who have no idea what a thermostat does/how it works other than "makes it hotter or colder" then we have much more difficulty building shared understanding of a feature request.
I also know this because 10 years ago that was my simple understanding of a thermostat... so it was much harder for me to understand why we were doing certain things.
[deleted]
It’s a little funny to read this since this is exactly how Scrum was meant to be.
The PO prioritizes tasks, but coming up with stories and breaking them down into actionable bits is a team responsibility, based on the PO’s input and product requirements.
This was subverted into PM roles that exert control over the backlog once Scrum made it into enterprise.
The PO prioritizes tasks, but coming up with stories and breaking them down into actionable bits is a team responsibility, based on the PO’s input and product requirements.
This was subverted into PM roles that exert control over the backlog once Scrum made it into enterprise.
I've also been thinking in a kitchen analogy to get management onboard to freeing up the tools used by engineers. There is a push to unify and breakdown silos, which is great, but in the eyes of management it also means using the same IDEs, the same OS, the same AIs etc.
My kitchen analogy is that the tools the engineers use are like the chefs kitchen knives, as long as the dish (code quality) is the same, engineers should be supported in choosing the tools that serve them best and the end results presented goes through a final pass (code review).
Back to the article, I disagree engineers should make the menu, it's not there job to know what the customer wants or to set prices. The engineers cook, the menu would be the maitre'd with the restaurant owner that decides (Yes, in a restaurant the head chef makes the menu and here the analogy breaks down.)
My kitchen analogy is that the tools the engineers use are like the chefs kitchen knives, as long as the dish (code quality) is the same, engineers should be supported in choosing the tools that serve them best and the end results presented goes through a final pass (code review).
Back to the article, I disagree engineers should make the menu, it's not there job to know what the customer wants or to set prices. The engineers cook, the menu would be the maitre'd with the restaurant owner that decides (Yes, in a restaurant the head chef makes the menu and here the analogy breaks down.)
Wasn't Agile supposed to bring the customer closer to the developers?
The menu is set, the diner complains about the price or the choice of side dishes, the chef iterates.
I don't see a lot of customer feedback in any of these PO loops, I'm witnessing it first-hand in my company. There's nothing Agile in this process anymore.
The menu is set, the diner complains about the price or the choice of side dishes, the chef iterates.
I don't see a lot of customer feedback in any of these PO loops, I'm witnessing it first-hand in my company. There's nothing Agile in this process anymore.
It’s true that some companies will place a PO in order to establish a hierarchy over a scrum team. But that’s not a scrum problem, it’s an organization problem.
In a reasonable team theres a dialog between product and engineering that establishes direction and priority.
In a reasonable team theres a dialog between product and engineering that establishes direction and priority.
Agree with the post from a practical perspective, the funny part is from a theoretical perspective all the arguments saying “scrum is wrong” will be wrong… since it is an agile framework it will always have the open way to say “the core says this…” which is really dynamic and agile by nature.
Based on my experience, one of the main issues describing the problem in post is associated with ego and management status… a lot of people in those positions feel like they’re better, superior to engineers forgetting exactly that they should be waitresses for engineers… the core issue is the structure, status and power associated to management and business related positions
Based on my experience, one of the main issues describing the problem in post is associated with ego and management status… a lot of people in those positions feel like they’re better, superior to engineers forgetting exactly that they should be waitresses for engineers… the core issue is the structure, status and power associated to management and business related positions
This definitely resonates with me as an EM at a fast moving startup. I would much rather have a mediocre product that addresses a real need than a perfect product nobody needs. That means my PMs generally need to focus more on understanding the users and the market (and getting everyone on the same page for that vision), not the implementation details.
Our PMs quickly sort issues into very broad priority buckets to save time, and engineering picks work according to those. If the PM on my team is spending 10 hours a week prioritizing issues that's 10 hours of user research, competitive research, and user acceptance testing we're missing.
Our PMs quickly sort issues into very broad priority buckets to save time, and engineering picks work according to those. If the PM on my team is spending 10 hours a week prioritizing issues that's 10 hours of user research, competitive research, and user acceptance testing we're missing.
I used to ask all those questions to my product owner. He was so annoyed by that. Almost got fired. Companies I worked for, everything is top down. Always. I gave up asking too much
All the arguments for where to place control over who decides what gets built IMHO are just political power grabs from one constituency or another. Different companies do it differently, and I'm not sure there is one best way. Any time engineering or product or sales or marketing want more power they come up with some reasons why their function should have more control in every company everywhere.
I don't think arguments that any function should always drive can be true, because who is best qualified to make those decisions is based on things like judgement, experience, domain knowledge, and customer understanding.
Instead of saying a specific function should have control, I think empowering the people who have been best a making decisions about scope should do it is the best approach. That can be engineering but that also can be product etc.
I don't think arguments that any function should always drive can be true, because who is best qualified to make those decisions is based on things like judgement, experience, domain knowledge, and customer understanding.
Instead of saying a specific function should have control, I think empowering the people who have been best a making decisions about scope should do it is the best approach. That can be engineering but that also can be product etc.
This sounds more like a complaint about broken communication in a team. While I'm not crazy about Scrum, this doesn't seem to be its systemic failure.
“Who are our customers?”
After the first 2 days on the project this should be clear, shouldn’t it? And all the other proposed questions are answered in the first 10 minutes on the first contact with the PO. 10 months later on the project the only thing that matters is what is needed and when.
After the first 2 days on the project this should be clear, shouldn’t it? And all the other proposed questions are answered in the first 10 minutes on the first contact with the PO. 10 months later on the project the only thing that matters is what is needed and when.
I disagree with this premise entirely.
A product owner is the conductor of the symphony.
Unless you have a team of experienced senior engineers, the engineers will lack the perspective and wisdom to make the proper choices.
A product owner is the conductor of the symphony.
Unless you have a team of experienced senior engineers, the engineers will lack the perspective and wisdom to make the proper choices.
Surely you've worked with a product owner who's invoked one of those "I'm not technical, but..."
I don't know of any working conductors out there who predicate their directions by "I'm not very musically inclined, but..."
I don't know of any working conductors out there who predicate their directions by "I'm not very musically inclined, but..."
I have been fortunate to only work with technical product owners, or ones wise enough to listen to the more technical when deciding a path forward.
I refuse to believe anyone not under threat of grievous bodily harm has written down the phrase 'In a dynamic, fast-paced world' of their own free will.
I think it can be a problem when the product owner role is strictly divided from the engineers.
But I've definitely seen it as a problem when the engineers take on product owner role. Engineers should definitely be thinking about user needs and those questions OP lists. But Engineers are too close to the code to be the actual responsible owner of deciding priorities based on user needs, or deciding what user needs take priority or are.
Product owner does need to be in the "kitchen" though -- product owner even in traditional agile scrum is supposed to be on the team every bit as much as the engineers, right? This is supposed to take care of the problem the OP mentions "make decisions in real time", "tight feedback loops, reassess, and make their next move" -- ABSOLUTELY, and agile and scrum as I understand it say the product owner is on the team to make this possible!
Things I think are true, to make things work:
* There absolutely needs to be a product owner who is not an engineer who "owns" user and business needs.
* They need to be on the team
* They should be in constant dialog with the engineers, educating them about user and business needs, and hearing their feedback and suggestions about how the engineers think they can best meet user needs. It should be a conversation engineers are included in, but Product Owner makes the call.
* the product owner (on the team) should not be the ONLY place engineers learn about user and business needs
* In addition to product ownewr responsbiel for "owning" user and business needds, there needs to be a technical lead who "owns" technical needs. (technical debt, efficiency including cost efficiency, etc; also team sanity needs!). In fact deciding what to do next can't be only up to the product owner and busniness/user needs. The time spent needs to be based on a combo of user/business needs with the product owner and technical lead in conversation -- but in this conversation the product owner (who is not an engineer) needs to "own" business/user needs, even if engineers are allowed to have an share opinions on them!
I have occasionally experienced this well oiled machine, and it works very well. As an engineer it is a huge RELIEF to have someone else responsible for human/business needs -- even though I do have an opinion about them and like to be educated about them, and think that's necessary to be a good engineer, and want that person to be interested in my opinion. But them having the responsibility (to the org) and final say over it leaves me feeling so much less stress, and able to focus on the technical problems and being the final say and authority and having accountability for those.
Getting this to work succesfully can't be done by just having the right structure on paper (although different structures can help or hurt), it takes skilled people who are about their jobs and get along and have experience that has given them some lessons on how to work together well.
A rare thing indeed.
But I've definitely seen it as a problem when the engineers take on product owner role. Engineers should definitely be thinking about user needs and those questions OP lists. But Engineers are too close to the code to be the actual responsible owner of deciding priorities based on user needs, or deciding what user needs take priority or are.
Product owner does need to be in the "kitchen" though -- product owner even in traditional agile scrum is supposed to be on the team every bit as much as the engineers, right? This is supposed to take care of the problem the OP mentions "make decisions in real time", "tight feedback loops, reassess, and make their next move" -- ABSOLUTELY, and agile and scrum as I understand it say the product owner is on the team to make this possible!
Things I think are true, to make things work:
* There absolutely needs to be a product owner who is not an engineer who "owns" user and business needs.
* They need to be on the team
* They should be in constant dialog with the engineers, educating them about user and business needs, and hearing their feedback and suggestions about how the engineers think they can best meet user needs. It should be a conversation engineers are included in, but Product Owner makes the call.
* the product owner (on the team) should not be the ONLY place engineers learn about user and business needs
* In addition to product ownewr responsbiel for "owning" user and business needds, there needs to be a technical lead who "owns" technical needs. (technical debt, efficiency including cost efficiency, etc; also team sanity needs!). In fact deciding what to do next can't be only up to the product owner and busniness/user needs. The time spent needs to be based on a combo of user/business needs with the product owner and technical lead in conversation -- but in this conversation the product owner (who is not an engineer) needs to "own" business/user needs, even if engineers are allowed to have an share opinions on them!
I have occasionally experienced this well oiled machine, and it works very well. As an engineer it is a huge RELIEF to have someone else responsible for human/business needs -- even though I do have an opinion about them and like to be educated about them, and think that's necessary to be a good engineer, and want that person to be interested in my opinion. But them having the responsibility (to the org) and final say over it leaves me feeling so much less stress, and able to focus on the technical problems and being the final say and authority and having accountability for those.
Getting this to work succesfully can't be done by just having the right structure on paper (although different structures can help or hurt), it takes skilled people who are about their jobs and get along and have experience that has given them some lessons on how to work together well.
A rare thing indeed.
Scrum is the problem.
Yeah I like this authors line of thinking, on some of my past teams the PM has hurt productivity by making decisions they should not be making.
Gave up after one sentence. Product owners do not have sole control over the product backlog.
Ideally, I want engineers focused on building, not taking discovery meetings with potential customers, messing around in Figma, projecting financials, writing ads, or any other role. I think some engineers like the side quests because they’re fun. In the kitchen analogy, we need cooks to do boring stuff like chop 100 onions and make dinner rolls. If everyone in the kitchen had to do market research at other restaurants, pick up ingredients from local farms, and test new menu concepts, the place would be out of business in short order.
Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.