> I think if you view developers through the prism of chasing dopamine highs from the pursuit of novelty, you can much better manage them.
I think the crux of it for me is that you cannot really ever know someone else, nor can you try control them like a puppet and it work. So you have to accept that you will often fail at trying to manage people in situations like this (and to understand your bosses, etc.), and you need strategies that work in the face of these factors.
But from another perspective, I'm not all that convinced about viewing developers the way you say, trying to indulge them then find a way to use the output. My alternative is to spend more time giving people good context - a programmer may be less inclined to chase their own technical novelty compulsions if you can give them an understandable and non-fake view of e.g. specific sales processes that need to be supported by development and what the significance is, company strategy, what the operations team is dealing with, etc. One of the simple older ideas in this area is having developers sit in on sales/customer meetings.
So I guess this is a kind of argument that alienation is part of the story of why technical people can often be totally unaligned with their company's goals and this is a barrier to improving this.
This may be a perspective coloured by my experience mostly working in small companies, not sure how well it translates to big ones.
> I think if you view developers through the prism of chasing dopamine highs from the pursuit of novelty, you can much better manage them.
I think the crux of it for me is that you cannot really ever know someone else, nor can you try control them like a puppet and it work. So you have to accept that you will often fail at trying to manage people in situations like this (and to understand your bosses, etc.), and you need strategies that work in the face of these factors.
But from another perspective, I'm not all that convinced about viewing developers the way you say, trying to indulge them then find a way to use the output. My alternative is to spend more time giving people good context - a programmer may be less inclined to chase their own technical novelty compulsions if you can give them an understandable and non-fake view of e.g. specific sales processes that need to be supported by development and what the significance is, company strategy, what the operations team is dealing with, etc. One of the simple older ideas in this area is having developers sit in on sales/customer meetings.
So I guess this is a kind of argument that alienation is part of the story of why technical people can often be totally unaligned with their company's goals and this is a barrier to improving this.
This may be a perspective coloured by my experience mostly working in small companies, not sure how well it translates to big ones.