4 ms·
> hidden motivations I guess you just have to ask why people have these motivations and why they hide them. It feels like people would act dishonestly first t
by erlich 4y ago
> hidden motivations
I guess you just have to ask why people have these motivations and why they hide them.
It feels like people would act dishonestly first to seek survival (job security), but then also to seek power (promotion/influence).
I wonder what the relationship is between survival and power. I guess at some point survival manifests into the desire to hold onto power. And the stakes get larger as the power accrued increases.
I also wonder how the human reward schedule plays into it. People are motivated by consistent rewards but at random intervals. If you take out the corporate power politics, you remove the randomness of the intervals, and it perhaps becomes less motivating. The chance for an early promotion provides motivation to play the game harder.
- jimwhite42 4y ago> I guess you just have to ask why people have these motivations and why they hide them. > It feels like people would act dishonestly first to seek survival (job security), but then also to seek power (promotion/influence). The first place I go to is to see that people aren't always doing good strategical thinking, then they get hung up on mistaken goals, or ineffective ways of achieving them, and aren't very good at communicating what they are doing or hoping to achieve, and this often leads to what looks like subconscious (or sometimes very conscious) obfuscation. In the technology area, I've worked with many coders, through to product people, sales, marketing, directors, etc., who get hung up on particular technical ideas - and claim these are strategic product or architecural decisions, and the same happens with people getting hung up on ineffective project management - especially when it's an approach that worked in another situation much better than it's working in the current situation.
- erlich 4y ago> aren't always doing good strategical thinking So it's not about being good at strategic thinking. It's about motivation, boredom and self-discipline. Here is what you are not seeing: Dev sits down to work on an assigned task. They might be on the ADD spectrum, and the work feels incredibly boring and their mind cannot focus on it. They are interested in novelty though. This provides a rush of motivation and hyper-focus. It will usually involve the choice of some cutting-edge new technology or architecture. For someone without ADD, it's hard to understand the intense pull of this pursuit of novelty. Tugging at you constantly. The problem is this motivation is derived from something that probably doesn't align with strategic goals of company. They will have super-human 10x levels of motivation. So they try to push the company in the direction of this novelty. They are just following a high for weeks on end. Eventually this high will run out though and the need to show progress towards business goals arrives, and they can't hide behind "rewrites", "tech debt", "unanticipated problems with new architecture", etc. So then the survival kicks in and the blame game starts with management. I think some of this is true for almost every developer. So when I read your complaints they are all easily explained: > hung up on mistaken goals...ineffective ways of achieving them They want to keep working on the novel thing that interests them. They try to shape the goals that allow them to do this. This can be subconscious. > aren't very good at communicating Because they have become too side-tracked by this novel thing or the next novel thing. > looks like subconscious obfuscation Yep. Exactly. It is often subconscious. To confront the reality of how far you have strayed from the strategic goals of the company would be like being out for a night drinking and at the height of the party, you have to leave and go immediately to bed. > Hung up on particular technical ideas - and claim these are strategic product or architecural decisions Just chasing dopamine. > people getting hung up on ineffective project management Survival. You went too far off track and need someone to blame. --- I think if you view developers through the prism of chasing dopamine highs from the pursuit of novelty, you can much better manage them. The only thing that can tackle this I think is having hard, concrete, and unavoidable deadlines. The survival system overpowers this creative exploration. But this usually only kicks in a couple of days before a deadline. Your strategic goals are essentially always competing with emotions of a developer towards some other thing. I think a lot of people underestimate the mania feeling that comes from the other thing. So you need to make the the dev believe the current strategic goals and the achievement of them is really, really, really important. This is why visionary/bombastic founders and so important. What could also help is allowing everyone to be open and honest about their true motivation and goals. But it would be hard for anyone to say: "I am only interested in playing with this new tech, and have no interest in the company". So there will always be a level of concealment. And usually, revealing such things will mean they are monitored more closely which they don't want so it doesn't make sense to reveal these things...or they will feel like they are being monitored which increases stress. In summary, deadlines and no bullshit.
- jimwhite42 4y agoGood comments, I mostly agree with them. > 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.