6 ms·

I have to disagree with the central argument, which is to give engineers more product management responsibilities. A way I’ve handled priorities as a PM is by s

• calflegal 2y ago
  > 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.
  • grecy 2y ago
    It’s all good though, because with experience the spray gunners can move towards being Picasso.
  • nick3443 2y ago
    Having dealt with some truly awful run & gun painters, it's visceral.
• meiraleal 2y ago
  > Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white. Led by one wannabe Picasso that never painted their whole life.
  • leetrout 2y ago
    Funny how that works, innit?
• jghn 2y ago
  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.
  • deleted 2y ago
    [deleted]
• evrydayhustling 2y ago
  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.
• Kinrany 2y ago
  > 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.
  • alwa 2y ago
    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.
    • bluefirebrand 2y ago
      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
      • Atotalnoob 2y ago
        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.
        • bluefirebrand 2y ago
• randomdata 2y ago
  > 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.
  • awill88 2y ago
    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.
    • randomdata 2y ago
      > 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.
• vault_ 2y ago
  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.
  • Spivak 2y ago
    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.
    • xnorswap 2y ago
      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".
      • eastbound 2y ago
        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!
• ricardobeat 2y ago
  > 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.
• bluefirebrand 2y ago
  > 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.
  • bluGill 2y ago
    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)
    • bluefirebrand 2y ago
      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
• MarkMarine 2y ago
  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.
  • bitwize 2y ago
    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 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.
    • vkou 2y ago
      Blaming enshittification, rent-seeking and blatant conflicts of interest on... SWEs with overly high opinions of their business acumen is certainly a bold claim.
• ubercore 2y ago
  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.
• dijksterhuis 2y ago
  > 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.
  • ungreased0675 2y ago
    You are correct. That’s what I meant but the wording should have been more precise.
• brightball 2y ago
  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-backlogs/ 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.
• intelVISA 2y ago
  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.
• bsoles 2y ago
  > 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?