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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
“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.
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.
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.
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.
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.
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.
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?
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.
Pain like this is critical feedback for a organization. Blunting it hurts more in the long term.
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 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)
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
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.
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.
Scrum is one kind of Agile. Kanban is another. I think I remember there being a third, but not sure about that.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
Software has decision making constantly, even at junior levels
Whitewashing walls has more or less no decisions other than what room to start in
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.
But what the OP said about "take this sprayer and make those walls white" is not
Don't conflate the two
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.
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.
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.
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.
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.
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.
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?
> 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
If a committee of chefs were to make menu decisions, it would be 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
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.
[0] https://blog.pragmaticengineer.com/the-product-minded-engine...
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.
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
"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 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.
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.
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.
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.
https://docs.google.com/drawings/d/1-6iUUbfFp3UFK24_OymF7ciX...
This is bad. If you know why you’re making money, it’s a lot easier to make the right decision.
> 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 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.
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
What?!
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.
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 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."
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.
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.
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)
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.
> 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.
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.
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.
> 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.
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.
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 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.
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.)
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.
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
In a reasonable team theres a dialog between product and engineering that establishes direction and priority.
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 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.
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.
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.
I don't know of any working conductors out there who predicate their directions by "I'm not very musically inclined, but..."