4 ms·

> Nobody on the software development team is talking with and observing the users of the software in action On every new project (usually internal enterprise s

> Nobody on the software development team is talking with and observing the users of the software in action On every new project (usually internal enterprise software) I plead to let me talk to the users. Every time in vain.

fouc 8y ago
If the customers are within your organization, can't you directly reach out to them? Don't ask for permission from a manager.
- wtracy 8y ago
  Tread with care. There are organizations where "going around management" gets you flagged as a loose cannon. It probably won't get you fired outright, but does destroy the goodwill that you will need to make meaningful changes down the road. Now, if you can do it without rocking the boat (perhaps without management ever finding out) then go for it.
  - fouc 8y ago
    It doesn't hurt to cc management at times or find a way to keep them in the loop on your immediate findings etc. That way it's just a demonstration of 'showing initiative' while still being a team player.
spamizbad 8y ago
Can you talk to the people who talk to the customers (The sales team)? It's indirect, and you need to isolate what's "real" and what's "If I had X feature I think I could close more sales"[1], but it's better than nothing. [1]which does have value, but not necessarily value to the customer.
clairity 8y ago
as fouc noted in a sibling comment, you shouldn't need to ask for permission to talk to customers if the organization is truly agile. however, the product owner (which i've been in various capacities) should bring a lot of customer information to the table so you can focus most of your time on development. it's unfortunate that your organizational structure prevents you from doing so.
- kashyapc 8y ago
  Even if a "Product Owner" brings a lot of customer information, it is still damn important for those developers who are genuinely willing (and able), to interact with customers—even if it is only via medium-bandwidth tools like video calls. Developers should not worry about spending some time talking to users.
  - clairity 8y ago
    we are not "disagreeing" that develoeprs have freedom to talk to customers. but if a developer spends most of their time doing something other than development, there are other inefficiencies going on.
    - wbl 8y ago
      Understanding the problem is development.
    - kashyapc 8y ago
      I know we agree on some level. Still, I can't help but feel like you have a somewhat narrow definition of "developer". A thoughtful senior developer who is in it for the long-run (read 15–30 years), and thinks in terms of "building a craft" will (and must) aim for a more well-rounded set of skills (that does not involve "development" in the narrow sense of hurling code)—e.g. giving high-quality technical talks that provide durable value, high-bandwidth interactions with customers and users, writing specifications, bringing multiple technical teams together to architect features and solutions (which requires careful and effective communication), and so forth. Related: You might've already come across it, if not, I suggest reading this paper (it's not about any specific technical topic, but more about the thought processes) from Peter Naur, titled: Programming as Theory Building. [1] http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf

fouc 8y ago

If the customers are within your organization, can't you directly reach out to them? Don't ask for permission from a manager.

wtracy 8y ago
Tread with care. There are organizations where "going around management" gets you flagged as a loose cannon. It probably won't get you fired outright, but does destroy the goodwill that you will need to make meaningful changes down the road. Now, if you can do it without rocking the boat (perhaps without management ever finding out) then go for it.
- fouc 8y ago
  It doesn't hurt to cc management at times or find a way to keep them in the loop on your immediate findings etc. That way it's just a demonstration of 'showing initiative' while still being a team player.

spamizbad 8y ago

Can you talk to the people who talk to the customers (The sales team)? It's indirect, and you need to isolate what's "real" and what's "If I had X feature I think I could close more sales"[1], but it's better than nothing. [1]which does have value, but not necessarily value to the customer.

clairity 8y ago

as fouc noted in a sibling comment, you shouldn't need to ask for permission to talk to customers if the organization is truly agile. however, the product owner (which i've been in various capacities) should bring a lot of customer information to the table so you can focus most of your time on development. it's unfortunate that your organizational structure prevents you from doing so.

kashyapc 8y ago
Even if a "Product Owner" brings a lot of customer information, it is still damn important for those developers who are genuinely willing (and able), to interact with customers—even if it is only via medium-bandwidth tools like video calls. Developers should not worry about spending some time talking to users.
- clairity 8y ago
  we are not "disagreeing" that develoeprs have freedom to talk to customers. but if a developer spends most of their time doing something other than development, there are other inefficiencies going on.
  - wbl 8y ago
    Understanding the problem is development.
  - kashyapc 8y ago
    I know we agree on some level. Still, I can't help but feel like you have a somewhat narrow definition of "developer". A thoughtful senior developer who is in it for the long-run (read 15–30 years), and thinks in terms of "building a craft" will (and must) aim for a more well-rounded set of skills (that does not involve "development" in the narrow sense of hurling code)—e.g. giving high-quality technical talks that provide durable value, high-bandwidth interactions with customers and users, writing specifications, bringing multiple technical teams together to architect features and solutions (which requires careful and effective communication), and so forth. Related: You might've already come across it, if not, I suggest reading this paper (it's not about any specific technical topic, but more about the thought processes) from Peter Naur, titled: Programming as Theory Building. [1] http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf