4 ms·

Give good devs a direct line to the customer and they're apt to always work on the right thing, but will spend a lot more time dealing with the customer and a l

Give good devs a direct line to the customer and they're apt to always work on the right thing, but will spend a lot more time dealing with the customer and a lot less time in development in order to do so. Leave good devs to play telephone through a middle-man, what we call the manager, and they almost certainly will work on the wrong things, but will have a lot more time to do it. I wonder which is actually more productive? Agile (of the Manifesto kind) posits that the former is most productive, but Agile (of the fake kind) seems to always want to revolve around the latter. The general sentiment is that fake Agile is the one that gets it wrong, so presumably cutting out the manager is what is most productive, but more data is welcome.

SoftTalker 2y ago
Disagree. The customer often has tunnel-vision on their needs, and doesn't know what's possible, and might have trouble even describing it except that their manager told them that their foo task was a problem. The devs have the opposite problem, they can imagine all sorts of new technology that would be fun to use (for them) in helping the customer solve their problems with doing foo, and even if they understand foo from the customer's business perspective they they may not have a great understanding of how big a problem it is in the grand scheme of things and what commitment of resources and expenses are justifed in solving it. Managers talking to managers can (in theory) draw some boxes around scope and priorities and get the right development problems solved at the right time. They may talk and realize that doing foo isn't even really a great idea and they should be doing bar intstead. Line-level employees working directly with developers will not be as likely to realize that. Developers can fall into the trap of thinking that because they are smart (mostly) at building software they are automatically smart about all the business processes and problems and goals of the company. They should certainly be informed about those things, but they are not experts in everything.
- randomdata 2y ago
  If we were talking about developers in general, perhaps, but we're specifically talking about good developers. They exist at the intersection of understanding the business, what customers are actually saying, and understanding the technology. Without that, what would make them good?
  - SoftTalker 2y ago
    Very very few of these people exist. They like to think that because they are very good at writing and understanding code and technology that they are automatically the smartest person in the room with every other aspect of the business. And I'm not talking exclusively about software developers, you'll find the same issues with anyone who is deeply smart and experienced at any one thing, thinking they must be smart about everything else too. There are a few polymaths out there, yes. But only a few.
    - randomdata 2y ago
      > Very very few of these people exist. Well, yeah, that's why they're considered good. Why they get a special title not given to everyone else. It would be nonsensical for "good dev" to refer to everyone who touches software development. "dev" would already communicate everything you need to know. The addition of “good” implies being set apart from what is typical.
mrits 2y ago
You generally don't want to act on customer feedback directly. Aggregating the feedback and making decisions at a broader level is a full time job. Of course, if you are an early stage startup and one of your customer is half your revenue, sure. Do whatever it takes to make them happy.
- randomdata 2y ago
  > You generally don't want to act on customer feedback directly. Obviously not literally. What they want hasn't been invented yet, which means the words to accurately describe what they want also haven't been invented yet. But ultimately you do want to act on what they really, truly are trying to tell you. Indeed, figuring them out is a hard job all on its own. > is a full time job. Sure. That's the tradeoff. You can spend most of your time figuring them out, and then the small few remaining units of time you have for development will be on point. Or you can play telephone and have all kinds of time for development, but will more often than not go down the wrong path. It's not really clear which is more productive at the end of the day. But we do know that Agile (of the Manifesto kind) pushes the former, while Agile (of the fake kind) pushes the latter. People seem to hate fake Agile more than they hate Manifesto Agile, so that does suggest that not playing telephone is more productive. But, still, data?

SoftTalker 2y ago

Disagree. The customer often has tunnel-vision on their needs, and doesn't know what's possible, and might have trouble even describing it except that their manager told them that their foo task was a problem. The devs have the opposite problem, they can imagine all sorts of new technology that would be fun to use (for them) in helping the customer solve their problems with doing foo, and even if they understand foo from the customer's business perspective they they may not have a great understanding of how big a problem it is in the grand scheme of things and what commitment of resources and expenses are justifed in solving it. Managers talking to managers can (in theory) draw some boxes around scope and priorities and get the right development problems solved at the right time. They may talk and realize that doing foo isn't even really a great idea and they should be doing bar intstead. Line-level employees working directly with developers will not be as likely to realize that. Developers can fall into the trap of thinking that because they are smart (mostly) at building software they are automatically smart about all the business processes and problems and goals of the company. They should certainly be informed about those things, but they are not experts in everything.

randomdata 2y ago
If we were talking about developers in general, perhaps, but we're specifically talking about good developers. They exist at the intersection of understanding the business, what customers are actually saying, and understanding the technology. Without that, what would make them good?
- SoftTalker 2y ago
  Very very few of these people exist. They like to think that because they are very good at writing and understanding code and technology that they are automatically the smartest person in the room with every other aspect of the business. And I'm not talking exclusively about software developers, you'll find the same issues with anyone who is deeply smart and experienced at any one thing, thinking they must be smart about everything else too. There are a few polymaths out there, yes. But only a few.
  - randomdata 2y ago
    > Very very few of these people exist. Well, yeah, that's why they're considered good. Why they get a special title not given to everyone else. It would be nonsensical for "good dev" to refer to everyone who touches software development. "dev" would already communicate everything you need to know. The addition of “good” implies being set apart from what is typical.

mrits 2y ago

You generally don't want to act on customer feedback directly. Aggregating the feedback and making decisions at a broader level is a full time job. Of course, if you are an early stage startup and one of your customer is half your revenue, sure. Do whatever it takes to make them happy.

randomdata 2y ago
> You generally don't want to act on customer feedback directly. Obviously not literally. What they want hasn't been invented yet, which means the words to accurately describe what they want also haven't been invented yet. But ultimately you do want to act on what they really, truly are trying to tell you. Indeed, figuring them out is a hard job all on its own. > is a full time job. Sure. That's the tradeoff. You can spend most of your time figuring them out, and then the small few remaining units of time you have for development will be on point. Or you can play telephone and have all kinds of time for development, but will more often than not go down the wrong path. It's not really clear which is more productive at the end of the day. But we do know that Agile (of the Manifesto kind) pushes the former, while Agile (of the fake kind) pushes the latter. People seem to hate fake Agile more than they hate Manifesto Agile, so that does suggest that not playing telephone is more productive. But, still, data?