3 ms·

I usually come back to my “products vs projects” division. Projects are discrete work efforts with a specific business objective and an end date. They’re effec

I usually come back to my “products vs projects” division. Projects are discrete work efforts with a specific business objective and an end date. They’re effectively waterfall, and managing a whole program with multiple work streams is at least possible via scrum (if you have the right feedback loops into the product team and execs). I suspect this is the kind of work people really hate. This is the kind of work consulting companies generally do. Product development should be much more free form. The product manager should own P&L for the product (or at least some proxy) because it aligns incentives. The dev team need not be 100% utilized all the time as their ability to quickly and effectively develop functionality is valued above cost efficiency (because again, product owns P&L so no business case has to be made). You can then use the “extra” time to deal with tech debt or take on special projects. The companies that really suck to work for are the ones that confuse the two. They are two different mindsets — one requires a developer who thrives on tight deadlines and can turn around functioning code and toss it over the fence, the other requires a more deliberate approach where doing things right preserves the ability to do things quickly. Put a project developer on a product they’ll be lost without the structure; put a product developer on a project team and they’ll quit within 6 months because they hate being micromanaged.

bennysomething 5y ago
Yes I tell everyone who ll listen this distinction too. I've arrived in a project based financial institution. It boggles my mind the software mind set: get project "done" toss / handover to some poor bastard to struggle with. Repeat. I actually think handovers should be banned. They don't work.
- wayoutthere 5y ago
  I used to lament “they’re doing it wrong” but I’ve come around to the fact that sometimes, that op model really is best for the size and way the company operates. If they don’t have technology product management as a skill in-house, it’s a seriously hard capability to build. In those cases, being able to work with an experienced vendor is great — but usually requires either time-boxed T&M or a deliverable-based contract (which is effectively timeboxed to protect the consultant’s margin). So you need to do handovers as your MSP / internal IT may not have the expertise to execute every project, and those (expensive, specialized) resources need to go away after the project is done.
  - bennysomething 5y ago
    I understand what you are saying, but this is all internally built stuff. The slopey shouldered mentally breeds a "don't give a fuck" mentality around code, testability, ease of new releases etc. I'm used to eat your own dog food.
pbourke 5y ago
This crystallizes for me that I’ve been a product developer mostly living in a project world (even when nominally building products). > the other requires a more deliberate approach where doing things right preserves the ability to do things quickly Yes. There is a surprising nonlinearity of benefits to doing something properly. It’s not about over-engineering to “best practices” or being a “cowboy coder” tuned only to your own preferences. These two are the Scylla and Charybdis of pursuing quality in software.

bennysomething 5y ago

Yes I tell everyone who ll listen this distinction too. I've arrived in a project based financial institution. It boggles my mind the software mind set: get project "done" toss / handover to some poor bastard to struggle with. Repeat. I actually think handovers should be banned. They don't work.

wayoutthere 5y ago
I used to lament “they’re doing it wrong” but I’ve come around to the fact that sometimes, that op model really is best for the size and way the company operates. If they don’t have technology product management as a skill in-house, it’s a seriously hard capability to build. In those cases, being able to work with an experienced vendor is great — but usually requires either time-boxed T&M or a deliverable-based contract (which is effectively timeboxed to protect the consultant’s margin). So you need to do handovers as your MSP / internal IT may not have the expertise to execute every project, and those (expensive, specialized) resources need to go away after the project is done.
- bennysomething 5y ago
  I understand what you are saying, but this is all internally built stuff. The slopey shouldered mentally breeds a "don't give a fuck" mentality around code, testability, ease of new releases etc. I'm used to eat your own dog food.

pbourke 5y ago

This crystallizes for me that I’ve been a product developer mostly living in a project world (even when nominally building products). > the other requires a more deliberate approach where doing things right preserves the ability to do things quickly Yes. There is a surprising nonlinearity of benefits to doing something properly. It’s not about over-engineering to “best practices” or being a “cowboy coder” tuned only to your own preferences. These two are the Scylla and Charybdis of pursuing quality in software.