Emotional Equations

This one always comes to mind:

Disappointment is the difference between expectation and reality

I think this is attributed to Chip Conley from “Emotional Equations”. I’m preparing to read this book. Interestingly, I hit this very same point (equation) when dealing with team members. It is an entirely different context than the book, which I should add.

One of the interesting constants in business is having to deal with the duel expectations of your coworkers and yourself. Almost in every instance, your expectations and your coworkers expectations will not align. This misalignment is a catalyst for disorder and conflict.

I’d like to keep exploring this idea in my next few posts.

Thoughts: Everything is awesome

Here are some thoughts for anyone reading this…

Most people think that they are doing better than most of their coworkers.

You may say, “but I feel like I’m not doing too well at my job.” That would put in the minority then. Most of your coworkers think that someone else is the problem. Everyone allows for the possibility that they are not preforming perfectly, but those are just minor discrepancies in a stream of better than average work.

This is all about perspective. Many individuals only see their work and not the work others do. Without knowing it, one can judge others on how helpful they are to achieving their own goals, not those goals assigned to the others they are observing. Without the proper perspective, you can’t judge the performance of your coworkers.

Keep in mind that this is possibly an issue your manager has with you. Your manager may judge you on how well you are helping them achieve their goals, while not truly understanding how well you are working toward the tasks assigned to you.

Thoughts: Nobody wants to be told what to do, even when they ask

Here are some thoughts for anyone reading this…

A developer shouldn’t have to ask for things to do.

If you have developers asking for work, you have problems.

There are two major things going on here. One, you have a developer who doesn’t know what the team is focused on. Two, you have a team that isn’t marketing, internally, what the priorities are.

Let’s start with #1. There are types of developers who want to be “tasked out.” They want a task they can take away, work on, then deliver for someone to verify. There is nothing wrong with this. Arguably, these developers are common. A team needs to know how to make the most out of these types of developers. The software process needs to supply them with work. These developers suffer when the software process and team structure cannot support them.

As for #2, you shouldn’t expect a developer to “just know” what to work on. You should expect a developer to know where to go to get the priority items to work on and where to get the information necessary to complete the work. If a developer is asking for work. More than likely, either there is no defined work to be done (no backlog), or the team isn’t able to convey the priorities and how to accomplish them.

A developer will only ask for something to do if they don’t have anything more interesting they want to do.

In the past, I’ve seen developers go for weeks or months without executing on anything significant. Most of the time, this has been because no one on the team was explicit asking them to work on an item. Moreover, they usually had something that was keeping their interest. It may have been an unrelated task or a side project.

At the end of the day, the core problem is the team being unable to work together cohesively. If a developer feels that nobody is aware of the lack of effort they are putting in towards the team’s goals, and takes that opportunity to work on items they are interested in or just not work at all, then the issue is with the makeup of the team.

Thoughts: Leadership change-ups are not what you think

Here are some thoughts for anyone reading this…

The biggest affect of changes in leadership is not a new leader’s ideas and strategies. It’s the change in the motivations of former subordinates.

When a leader is replaced, the immediate effect is constraints that were placed on subordinates are removed. Sometimes these constraints are explicit directives and sometimes they are due to implicit motivations.

Employees don’t challenge their leadership, they just stop working for them.

Employees who don’t respect their leadership often use indirect means of undermining their work. A good read on this topic is Simple Sabotage (affiliate link) . A change in leadership has the intimidate effect of giving the workers the motivation to show that they are not the problem, and their former leadership was the problem.

Teams are successful only when they are willing to cooperate as a group to succeed. There are no single successes.

Good leaders can be effective, set strategy, and direct the course of business. Just like every other worker, it takes time for them to do this. Therefore, any alteration seen in the overall effectiveness of a team due to leadership changes are due to the willingness of workers to succeed where they were not before.