Are you more likely to book your next vacation through LastMinute.com or through PlanWayAhead.com? Do you make snap decisions or like to keep your options open? Are you usually the first to meetings or the last? Do you like to arrive at the airport with seconds to spare or would this send your stress sky high? Is your desk clean or chaotic? Are deadlines your friend or foe? Do you like to focus on a task to completion or have many balls in the air? Do you always finish what you start? Are you a procrastinator?
These behaviors are tied together on psychological scales. Awareness of your natural behavior has its benefits, not least that it gives you greater opportunity to consciously adjust your behavior according to circumstance.
Recognizing and understanding the decision-making style of colleagues has its benefits too. It can reduce tension and misunderstandings between people with different styles. It can help like-minded individuals to avoid group-think. It allows diverse teams to play to the strengths of individuals.
Warning: this blog includes actual codes of ethics. Reading codes of ethics may result in drowsiness. Do not read this blog while driving or operating heavy machinery.
Last week’s psygrammer post, Sharing Benefits Increases Cheating, was a glimpse on how people make (un-)ethical judgements and creating a working environment that fosters ethical behavior. As I reflected on that post I realized that ethics was rarely an explicit part of my working environment: no employer had a code of ethics (that I knew about) and it was rarely a direct topic of conversation in the workplace. Sure, I faced many ethical dilemmas and I feel that I have sought to act ethically throughout my career. But what are the ethical principles that I am supposed to uphold? Will it make it easier to recognize ethical dilemmas and make ethical choices if I know the individual “ethical lemmas“?
Today’s post is a thought bubble on honesty and cheating in the workplace following two articles I read recently. The first is an interesting report on how people are more likely to cheat if the benefits of that cheating are shared with another person, even with an anonymous stranger. The likelihood of behaving dishonestly doubled (21% to 43%) when participants could point to another’s benefit from their own unethical behavior.
The report was based on experiments involving word games and other online activities in which the researchers left opportunities for participants to over-report their performance. Splitting the benefits of cheating was considered less unethical by participants than taking the benefits all for themselves.
I think we are all entitled to some basics in our working environment; to be rewarded fairly for our contributions, to work safely, to be allowed to act ethically, amongst others. There are some people who, however, hold an exaggerated sense of entitlement. They might feel they have a right to be given things which others believe should be obtained through effort. They expect favorable treatment. They can expect others to automatically comply with their wishes. Working with or managing the entitled can be demanding for colleagues and managers alike.
Where the sense of entitlement is greater we are talking about narcissism. Narcissist behaviors can be particularly difficult to deal with. From my own experience and from researching on this article I have heard many stories of the destructive impact that narcissists can have on colleagues, managers, teams and even entire businesses.
How do you recognize and deal with somebody who lives with a sense of entitlement or has a narcissistic personality disorder?
Today, many programmers collaborate remotely. Some collaborators will never meet in person. Some will not even meet by phone or video conference and so will collaborate solely through textual encounters.
With so many distributed teams it is important to ask whether physical interactions provide software teams with an advantage and what can be done to facilitate teams collaborating across distance and time zones.
Today I step cautiously into the realm of the “Alpha Geek” and of team hierarchies, power and dominance behaviors amongst programmers.
Hierarchies, or the “Pecking Order“, are part of human social life just as they are a part of animal life. Any social hierarchy implies that there is dominance. Dominance is achieved through behavior. Gorillas beat their chest; chickens peck; grizzly bears stand on their hind legs.
I’ve never seen chest beating (literally) or pecking in a programming environment. But I’ve seen plenty of people stand up to exert authority and many other forms of dominance behavior.
So there is no confusion, it is not my objective to provide a how-to guide for dominant behaviour. This post is about recognizing dominant behavior and today we start with audience behavior at presentations.
Last week’s post about misunderestimations (part 1) considered the practical difficulty of estimating software effort. Uncertainty of estimates is created by complexity and the infamous, but poorly understood, “unknown unknowns”. The uncertainty is too often ignored.
Consider the best way to estimate…
Team Lead: I need to know precisely how long task X will take.
Programmer: First, I will do the task. Then I’ll get back to you with an estimate of how long it took.
Since we can’t rely on hindsight we are stuck with foresight and this is susceptible to many irrational and emotional biases: pride, competition, leading questions, peer pressure, conditioning, poor communication amongst many other effects. These can wreak havoc on the accuracy of estimates even, in my experience, for rational programmers.
This post explores these biases and how they lead to misunderestimation and its rarer sibling, misoverestimation.