4 ms·

One question I have when I see articles like this is: what are the downsides of this sort of person on a team? What kind of projects should they not be involve

by sanj 7y ago

One question I have when I see articles like this is: what are the downsides of this sort of person on a team? What kind of projects should they not be involved in? When are they the wrong person for the situation?

todayispotato 7y ago
They will probably not be an extremely deep expert into specific technologies, and they will burn out on doing work that does not involve improving the product for actual users. They want to deliver a feature, and sure they want to make sure it's being used well, but they won't want to stick around to endlessly tweak it.
- nevertoolate 7y ago
  I don't necessarily agree. Being a responsible product person both means tweaking good features, sunsetting bad features and introducing new ones.
jasonbourne1901 7y ago
This type of engineer probably isn't a good fit for some software projects are heavily replication based - think of replicating a bunch of canned reports with slightly different sort orders, filters, etc. The scope of the project is very well known, there is zero discovery work to be done, they just need to poop out a pile of reports quickly and move on. Also consider if you are an off-shore provider of software engineers to customers who value having remote engineers who will "just do what they are told" This sort of person is likely not going to be actualized in that kind of a situation.
koreth1 7y ago
At a guess: Any team that's working on substrate rather than on code that customers directly interact with won't be a good fit, unless the person has a very flexible view of "customer" and "product." Like, if your team is working on performance improvements for your company's data storage layer, the mindset described in the article won't bring a lot of benefit, I think.
- LegitGandalf 7y ago
  If the storage layers are plenty fast enough and they ask the question that gets their effort redirected to the right thing - that's gold! Now, as an engineer I gotta say, we need MOAR speed! :)
desc 7y ago
This, very much. There are projects where there are multiple sets of 'users' who don't necessarily overlap, and you'll find someone like this championing one set to the detriment of others. This can be awkward to imagine in the context of internet apps where there's a 'product' and people use it, but in the context of business or government applications where the customer-facing product is not merely the frontend it can be very relevant. If you're producing software which runs on each customer's own servers, as an independent system instance, the user-stakeholders include: * The people using it in day-to-day tasks. These are the 'Users' an internet-based application usually considers. * The ops guys looking after those servers, who have no other power over the software system itself (but will lose their weekends when eg. the vendor-documented backup procedure turns out to be incomplete). * Other vendors, who probably have to integrate with the system (and will curse the documentation or lack thereof). * The customer's internal helpdesk fielding end-user queries about the system (frantically hunting through a content-free manual, if they're new to the job, or escalating without comment, if they're burned out). * The Administration, who want reports on the behaviour and performance of the Users mentioned above (and often don't care about usability as long as the reports are pretty). * And many other groups, with entirely different concerns. A great many of these articles seem to either champion only the 'User' and/or refer only to systems where all other parties are internal to the company building the software. The world still relies heavily on a lot of systems which do not conform to the Cloud ideal. It is important for any 'product-minded software engineer' to remember that, sometimes, making eg. the Ops guys' job easier will make life better for All Of The Above, even more than chasing after that shiny report Admin wants. Of course, if you are building in the Cloud, The Above are largely your coworkers and should make all of this known to you :P

by sanj 7y ago

todayispotato 7y ago

They will probably not be an extremely deep expert into specific technologies, and they will burn out on doing work that does not involve improving the product for actual users. They want to deliver a feature, and sure they want to make sure it's being used well, but they won't want to stick around to endlessly tweak it.

nevertoolate 7y ago
I don't necessarily agree. Being a responsible product person both means tweaking good features, sunsetting bad features and introducing new ones.

jasonbourne1901 7y ago

This type of engineer probably isn't a good fit for some software projects are heavily replication based - think of replicating a bunch of canned reports with slightly different sort orders, filters, etc. The scope of the project is very well known, there is zero discovery work to be done, they just need to poop out a pile of reports quickly and move on. Also consider if you are an off-shore provider of software engineers to customers who value having remote engineers who will "just do what they are told" This sort of person is likely not going to be actualized in that kind of a situation.

koreth1 7y ago

At a guess: Any team that's working on substrate rather than on code that customers directly interact with won't be a good fit, unless the person has a very flexible view of "customer" and "product." Like, if your team is working on performance improvements for your company's data storage layer, the mindset described in the article won't bring a lot of benefit, I think.

LegitGandalf 7y ago
If the storage layers are plenty fast enough and they ask the question that gets their effort redirected to the right thing - that's gold! Now, as an engineer I gotta say, we need MOAR speed! :)

desc 7y ago

This, very much. There are projects where there are multiple sets of 'users' who don't necessarily overlap, and you'll find someone like this championing one set to the detriment of others. This can be awkward to imagine in the context of internet apps where there's a 'product' and people use it, but in the context of business or government applications where the customer-facing product is not merely the frontend it can be very relevant. If you're producing software which runs on each customer's own servers, as an independent system instance, the user-stakeholders include: * The people using it in day-to-day tasks. These are the 'Users' an internet-based application usually considers. * The ops guys looking after those servers, who have no other power over the software system itself (but will lose their weekends when eg. the vendor-documented backup procedure turns out to be incomplete). * Other vendors, who probably have to integrate with the system (and will curse the documentation or lack thereof). * The customer's internal helpdesk fielding end-user queries about the system (frantically hunting through a content-free manual, if they're new to the job, or escalating without comment, if they're burned out). * The Administration, who want reports on the behaviour and performance of the Users mentioned above (and often don't care about usability as long as the reports are pretty). * And many other groups, with entirely different concerns. A great many of these articles seem to either champion only the 'User' and/or refer only to systems where all other parties are internal to the company building the software. The world still relies heavily on a lot of systems which do not conform to the Cloud ideal. It is important for any 'product-minded software engineer' to remember that, sometimes, making eg. the Ops guys' job easier will make life better for All Of The Above, even more than chasing after that shiny report Admin wants. Of course, if you are building in the Cloud, The Above are largely your coworkers and should make all of this known to you :P