Luis Gonçalves's Blog, page 13

Scrum Master as a Servant Leader

Servant Leader

In the SCRUM world, a Scrum Master is often known as a Servant Leader, but I believe that very few people actually know what a Servant Leader really is. Based on this assumption, I am writing this blog post to explain what a Servant Leader is and what the characteristics of a good servant leader are (in this case, a Scrum Master). I will start by using the Greenleaf definition of what a servant leader is:

The servant leader is servant first. It begins with the natural feeling that one wants to serve. Then conscious choice brings one to aspire to lead. The best test is: do those served grow as persons: do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society; will they benefit, or, at least, not be further deprived? (Greenleaf, 1977/2002, p. 27)

Larry Spears in his article: “Character and Servant Leadership: Ten Characteristics of Effective, Caring Leaders” explains that servant leadership seeks to involve others in decision making, is strongly based in ethical and caring behavior, and enhances the growth of workers while improving the caring and quality of organizational life.

In the same article, Larry Spears explains that a good servant leader has 10 characteristics that are of critical importance:

Listening

The servant leader must be willing to listen and identify the will of a group. Hearing it will give him the opportunity to clarify that will. The leader must be able to listen and reflect on what is being said; this is an important aspect of being a servant leader.

Empathy

Empathy is quite an important characteristic for a servant leader to have. A servant leader must accept and recognise the special and unique spirits that exist in each different person. They cannot reject coworkers and colleagues as people, even in difficult conflict situations. A successful servant leader is a great empathetic listener.

Healing

This can be considered one of the strengths of a servant leader: The power of healing one´s self and one´s relationship to others. Servant leaders understand that they can take on a special role within their team/group. They have a special power to fix relationships.

Awareness

Awareness helps people to become stronger. Awareness helps the servant leader to understand issues involving ethics, power, and values. This characteristic helps any servant leader to be able to view situations from a more holistic and integrated position.

Persuasion

A good servant leader tries to convince others, instead of forcing compliance. Usually a successful servant leader is great at building consensus within teams.

Conceptualisation

Transforming a big vision into small workable pieces that everyone understands is a great characteristic servant leaders generally have. They have the ability to pick up on daily problems and conceptualise solutions that are understood by everyone.

Foresight

A great servant leader has the capacity to foresee the likely outcome of even the most difficult situation. Using previous experience and present data, they can predict with great accuracy the future outcome of a situation.

Stewardship

Servant leadership involves an inherent commitment to serve the needs of others. It also emphasises the use of openness and persuasion, rather than control.

Commitment to the Growth of People

Servant leaders believe in true intrinsic motivation. They believe that all people have a lot to contribute to the organisation. A great servant leader is committed to helping people to grow within the organisation.

Building Community

Building a community among those who work within a given organisation is the last characteristic of a great servant leader. They believe they can create true communities among the people that work within the same organization(s).

If you liked this idea and you want to receive many others subscribe the mailing list below. I promise to deliver only high quality content.

Subscribe to my mailing list

Luis

The post Scrum Master as a Servant Leader appeared first on Welcome to.

Without an outcome in mind, any road will do!

Having an outcome defined, whether it’s for an event, phone call or meeting is very important. To quote Lewis Carroll, Alice in Wonderland:

“Alice came to a fork in the road. ‘Which road do I take?’ she asked.

‘Where do you want to go?’ responded the Cheshire Cat.

‘I don’t know,’ Alice answered.

‘Then,’ said the Cat, ‘it doesn’t matter. If you don’t know where you are going, any road will get you there.”

This eloquently explains how important having an outcome is. Without an outcome in mind, any direction will do.

How often have you attended a meeting, either one on one or with a group? After reviewing the agenda did you feel confident that you understood what the meeting was about? Have you ever been in a meeting where the agenda flew out the window? Have you ever attended meetings where discussions head off in a direction that the agenda didn’t cater for?. The agenda provides the framework, but is it understood that the items on the agenda are the reason everyone is there and wanting to have a discussion? How do you think the meeting could turn out if everyone attending had an outcome in mind, and that outcome was shared at the start of the meeting? Do you think the meeting could be more focused?

From my experience, having a shared outcome encourages a more focussed and productive meeting. The fact that everyone attending has a shared understanding of the intended outcome, any discussion deviating from the agenda/outcome can be challenged in terms of whether it is adding value towards the desired outcome.

In my opinion, a well-defined outcome is more important than having an agenda. An agenda, in a project management context, is similar to a waterfall approach. Planning is carried out upfront when the least about the project is known. Having a fixed agenda means that anything that is discussed, that is not on the agenda is like scope creep, and the agenda is no longer the agenda. This often results in additional meetings required to discuss the items on the agenda which weren’t discussed in the last meeting. We don’t know where we are going, so any road will do. Having a flexible agenda, or a very loosely defined one, and having a well defined outcome for the meeting, means that you are focussed on the outcome rather than trying to stick to a rigid agenda. There is a common destination, so the direction can be discussed upfront on how to get there. Going through a list of items on an agenda, could mean that all you are discussing is a number of possible directions you could take, without knowing where you are going. As a group, you can share and decide what the common destination is and in that way, you can choose the best road to get you there.

How can this be applied in an Agile environment, or in fact any environment?

Lets start by looking at a few of the Scrum ceremonies.

In the daily stand up, what is your expected outcome for the stand up? What is the team’s outcome for the stand up? It may be assumed that they are the same, or maybe you are just following the process and expect the outcomes to based on Scrum theory i.e. what did we do yesterday, what have we done today and are there any blocks?

What about retrospectives? Generally we all expect that we will use the retrospective as an opportunity to reflect and come up with one or two improvements. So far, these two ceremonies fulfil a relatively specific need, and maybe the assumptions are correct; maybe!

Looking at the backlog refinement meeting, which could serve multiple purposes. What are your expected outcomes? What about the team, PO or other stakeholders? Do they have an outcome in mind?

Having your own outcome for every meeting and sharing it is very important. Looking at a retrospective as an example, you could invite the team to discuss what their own outcome, in general, for retrospectives would be. These could then be discussed and a set of outcomes for the retrospectives could be agreed on. This would be a general guide for retrospectives. It would still be worthwhile discussing what each individual’s outcome for each meeting is, at the start of each retrospective, or any other meeting.

Not everyone attending a meeting will be aware of the fact that they should have an outcome in mind. Simply start the meeting by asking “What is your expected outcome of this meeting?” Equally important, would be to check if those outcomes had been achieved at the end of the meeting. Did you arrive at the destination you had in mind?

As mentioned, this is not restricted to an Agile environment, or even meetings per se. It could be a meeting with a new prospective client or a business phone call as an example. Have your own outcome in mind, and try and elicit the outcome of the person you are having the discussion with. This can be direct e.g. “What are your expected outcomes from this meeting” or you could use other questions to be less obvious, either will do. The difference depends on your relationship and, you guessed it, what your outcomes are.

In the end, if you don’t have an outcome in mind, any decision you make will do. So like Alice, once you have decided where what your outcome is, how much easier is it for you to select which road you should take?

Blog Post by Dillon Weyer

www.anuvu.co.za

@dmweyer

The post Without an outcome in mind, any road will do! appeared first on Welcome to.

Anti Pattern – Change Scrum Master often

Changing the Scrum Master role within the team is something that I hear time to time. Fortunately not that often. The defenders of this theory claim this is beneficial for the team and for the different team members. They think if people change the role of Scrum Master all team can understand what are the difficulties and challenges of a Scrum Master and therefore be more understandable with colleagues.

Another reason that I heard recently had to do with the fact that scrum masters were part of a central team, and having them rotating between teams would improve their knowledge sharing within the central team. In my opinion this does not make any sense. First I do not agree at all with central teams composed of coaches or scrum masters, you can see my view in this blog post: “Nightmare – Central teams consisting of coaches“. Second I could already see how both scrum masters and teams would be frustrated in changing teams every couple of weeks.

Some people argues these ideas are possible because the role of scrum masters is to make himself disposable therefore if teams do not need them they can change place. In my opinion this argument is strange, of course scrum master role is to make himself disposable but to reach that level the team must be quite mature. And if the team reaches that level scrum master is not necessary at all therefore there is no need for rotation because there is not even need for scrum master.

The basic idea behind all these suggestions relies on the fact that people feel the need to share knowledge. In this point we are align, I truly believe that knowledge sharing is something important, I have wrote a blog about it. I defend if you do not create a knowledge transfer culture you will die, more details here. So in order to share knowledge you have several ways, this blog post present you several of them.

The big problem of this idea relies on the fact that every time a person within a team change the interaction between peoples change. People that are aware of the four phases of a team: The Forming – Storming – Norming – Performing, know that these phases are all necessary and inevitable in order for the team to grow, to face challenges, to tackle problems, to find solution, to plan work and to deliver work. Every time a person change within the team the team goes back on these four phases, forcing some kid of reset to the team.

I hope that I was able to explain why changing scrum master often causes problems to the teams.

If you liked this idea and you want to receive many others subscribe the mailing list below. I promise to deliver only high quality content.

Subscribe to my mailing list

The post Anti Pattern – Change Scrum Master often appeared first on Welcome to.

Accountability? No sense

Accountability? No sense

Hi guys, in this post I want to get your help to understand why 99% of our management does not have any clue how companies or people work. Some time ago I worked for a company that went through a big reorganization. At that time I was an agile coach and my role changed a lot. The new management clearly stated there was no space for coaches in that organization, instead we need development managers for each team and product. They mention there was a big problem with accountability and development managers would solve that problem, when I listen that I just wanted to cry, I could not believe how much clueless people can be.

During several months the company had problems in putting out a product with great quality and top management continuously blamed development teams for all these problems, but in reality every six to eight months they did perform huge changes to the environment not allowing any stable environment for people to work on. So with the new re organization new persons were putted in charged and some of them came up with the idea that all the problems were lack of accountability, their solution?

Put development managers in all teams to create accountability.

In their view accountability was the problem and putting a person there as manager would solve all the problems. At that time I did not know if I should cry or laugh of such lack of understanding of how systems works. At that time I offered my help in order to help a couple of teams to improve but my help was refused, all the help that teams should receive should come from development managers because they were the ones becoming accountable for teams success so they should take care of everything.

At that time I asked:

But are we changing something in the way how we work? What big changes are we doing in order to succeed this time?

And without no surprise of course they were not planning to change much, they expected just because they someone is accountable, something would change even if nothing in the system would change. This is where I see that most of the times putting people accountable for something and not changing the system around is purely stupidity. You can put there 1001 different persons that most probably the outcome will be the same, if the system does not change the outcome will not change no matter who is accountable so for me most of the times accountability is a pure joke.

And now you may think that these people could bring new ideas and new ways of working, but in reality these people were already in the company and they changed from Line Manager to Development Managers, now instead of being responsible for people they were responsible for the release of the product but all the rest was exactly the same. So my question is if they were not able to help people before how can they help them now? My answer: they cannot!!!.

A lot of companies and managers think that accountability is the solution to make things work but in reality accountability is kind of useless if you do not understand how the whole system works around you, and this is one of the biggest problems of nowadays management, they do not have any clue about system thinking. This is a crucial area that managers need to dominate otherwise they will never understand how to take their companies into the right direction.

If you liked this idea and you want to receive many others subscribe the mailing list below. I promise to deliver only high quality content.

Subscribe to my mailing list

The post Accountability? No sense appeared first on Welcome to.

SMART objectives are DUMB objectives!!!

Some weeks ago, I spent a full day in a workshop where I was forced to define SMART objectives for a big program. Now, being a survivor of the aforementioned practice, I can affirm that SMART objectives are a dumb way to work. Before you leap to correct me, let me explain my point of view.

The objective of this workshop was to bring people together. Senior management had the feeling that people were not aligned, that they did not truly understand what the company should deliver and by when. Having the workshop was supposed to bring people together and align everyone so that they were all moving toward the end goal. Up to that point, nothing seemed amiss to me, but things got messy when I figured out the facilitator of this workshop was an “old school” business consultant.

He started the session explaining to us that we would define SMART objectives for the whole program in order to align everyone to a common goal. When I heard this, I made a huge effort to keep quiet. Some of my colleagues who are familiar with me and my views were looking to me, waiting for the moment of my explosion.Things got even messier when he started to talk about Management By Objectives.

In this blog post: “SMART Objectives trap!!! Be careful when your boss establishes them” I give a thorough overview of why I think SMART objectives are DUMB objectives, but I want to better explain why I am against this kind of approach.

We live in a chaotic world; changes happen at speed of light and we cannot predict how and when things happen, we just need to be fast and adapt fast enough to survive. Companies are no different—actually, for companies, it is even more important to adapt quickly than it is for us. So, if we live in a society where change happens everywhere, why do we still agree with consultants who want us to define every single goal of a huge program for an 8 month period of time?

Moreover, after having all these SMART objectives defined on a Program Level, he wanted us to cascade all these SMART objectives through the organisation for each different individual—yes, this means imposing individual goals!!! In case you do not know, I am writing this book: “Getting Rid of Performance Appraisals” where I explain that goals cannot be imposed, people must feel connected to the big product and define goals for their own teams.

Establishing SMART Objectives for eight months for the whole organisation, cascading them down to individual level, is a huge waste of time. In two months’ time everything could change and we would need to go through the same process all over again; WHAT A WASTE OF TIME!!!

So, what can we do instead?

My friend Vasco Duarte has a workshop where he helps Product Managers to create a product vision. More can be found here. Basically, he brings product managers together and helps them to create a vision. Together they define a product vision that is aligned with the organisational vision of the company. Vasco helps them to identify the major features of the product and what is mandatory as part of the MVP.

With a clear product vision defined and aligned with the company vision, it is up to the company to create teams with the right skill sets (in order to be able to deliver the right product). Having formed a team vision, the team can then start to define objectives in order to achieve the team, product, and company vision. All of them are aligned, bringing everyone toward the bigger purpose.

I just wanted to make sure, in this case, that we have TEAM objectives—not individual objectives. Of course, each different individual can define their own objectives (or even better, can ask colleagues for feedback regarding where he can improve). Nowhere in this situation is anything imposed; instead, this is always something that comes from the person or from his peers.

It’s quite common to ask for new things, but to get them we must achieve new things and try new things. Like Peter Senge says: “It´s not enough to change the structures if the mindset behind does not change”. If you really want to make a difference and become an agile company, stop using old-fashioned methods that are outdated and proven to be wrong.

If you liked this idea and you want to receive many others subscribe the mailing list below. I promise to deliver only high quality content.

Subscribe to my mailing list

The post SMART objectives are DUMB objectives!!! appeared first on Welcome to.

Is the Project scope realistic?

Project scope is an interesting topic. During last several weeks, I have been involved in planning the release of our new product. This post explains the way I worked with the C level, and how I helped them to understand whether the project scope was realistic. I also explain how we executed the release plan for this particular project.

In our case, the release date was fixed. Ultimately, we had a date we could not miss. Otherwise, our company would encounter immense problems. Knowing this, we found it necessary to understand whether the project scope was realistic enough to proceed with the plan. When I had the opportunity to talk with the CPO, he explained that we needed X amount of features. Therefore, they would need my help to determine if it was possible to deliver all of those features on time.

First, I needed to examine the historical data, in order to define the project scope. Because, if I study the data, then I can find out how many stories we were delivering, and, at the same time, map those stories into features. Then, I would have a general idea of how long it would take us to deliver all necessary features. Now, you may be thinking, not all features are the same. So, how can I choose this approach?!

Yes, you are right, the features are indeed different. Yet, my experience tells me that features converge, and the number of features delivered per sprint, or per month, gives us a good knowledge base. We can use this to track where we will end up in the future.

Then the problem started, I analyzed the old data, and realized that we did not have any relationship between features and stories. We only had information for feature releases. As a result, how could I figure out where we would end up, if all of our previous data was useless?

Next, we decided to request the top priorities from Product Management. We asked them to identify what the most important features of that release were. This way we ensured that we were always working with the highest priority features.

Afterwards, we asked the teams to break those particular features into stories. It is important to note, we only asked for the number of stories that would fill the first two sprints. More would have been a pure waste of time. Based on previous knowledge, after two sprints all stories will be different.

With this approach, we were able to calculate the number of stories each feature has on average. Then, we could record the previous speed of the teams, and predict where we should end up, more or less. For example, we determined that each feature contained five user stories, and each team was delivering five stories per sprint. Therefore, each team could deliver one feature per sprint. Also, in this particular project, we had five teams, which means, we could deliver five features per sprint.

In our initial release plan, we had approximately fifty features. This meant we would need ten sprints, in order to deliver all the required features. Now, we had a general idea as to whether the project scope was realistic or not. With a fixed release date and the known rate of features, we could predict where we would finish up.

This is a complex topic! Many people prefer a different method, but I must say, this method has worked quite well for me. It has proved to be an excellent way to determine whether the initial project scope is realistic.

Of course, this is just the beginning. Later, we will create a Release Burndown Chart. This is where we can track the progress towards our goal every week. This close examination of the weekly course gives us the precise information we need, in order to establish where we will end up. Then, with this information, Product Management can always see where we are, and can to remove features accordingly, to accommodate the release date.

I hope you enjoyed this blog post. Vasco Duarte also has some really interesting information about this subject. If you want to follow his blog, you can find it here.

If you liked this article and you do not want to lose future ones Sign In to the mailing list below.

#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; width:500px;}
/* Add your own MailChimp form style overrides in your site stylesheet or in this style block.
We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */

Thank you so much,

Luis

The post Is the Project scope realistic? appeared first on Welcome to.

Rewards may destroy improvement efforts in our companies

http://kelseyrush.com/wp-content/uplo...

In the book, Punished Rewards, Alfie Kohn states, “Rewards do not require any attention to the reasons that the trouble developed in the first place.” He explains how rewards ignore the root cause of the problems. In general, we believe rewards will get others to do what we want.

As parents, if our child is screaming and crying, will we simply offer him candy? This will keep him quiet, but we are not trying to understand what is causing the problem.

How about when the child is in school, will we offer him something nice to improve his grades? Will we punish him if they do not get any better?

Several companies work the same way, when they want to something done, managers offer bonuses to their employees. But, what is wrong with this approach?

“Rewards make us forget what are the root causes of the problems”

These tactics are just a form of bribing people, so that they will do what we want them to do. When we do not explore the possible root causes of the problems, we will never get any real solutions to the issues. It is as Alfie Kohn says, “Rewards are not actually solutions at all; they are gimmicks, shortcuts, quick fixes that mask problems and ignore reasons. They never look below the surface.”

In fact, Freudians have defended this very viewpoint for decades. They believe that this kind of behavioral therapy only addresses the symptoms, instead of the deeper problems. (Alfie Kohn, Punished by Rewards p. 60).

Offering rewards is a common practice in many companies, they promise incentives to departments, in order to increase in their performance. Even though the administration will see a short-term increase in productivity, the improvement is artificial. The underlying problem, causing the lack of productivity, is not addressed at all. Employees will work extra hours just to achieve the bonus, and then do not care about additional improvement efforts.

As soon as companies issue rewards, in order to increase productivity, employees will always expect incentives in the future. This means that any future improvement efforts will be destroyed, because administration continually has to bribe its employees with bonuses or rewards.

We live in a society where companies only look at the bottom line, and just care about quarterly results. This makes managers impatient for results, and therefore they commonly use rewards programs, to motivate employees to increase production in organizations. Unfortunately, the use of this reward system will never help companies understand the underlying problems. As a result, long-term improvement will never be possible. If companies continue to use this approach, then I am sure we will have the exact opposite outcome of what we want: fewer and fewer employees will care about actual improvement efforts.

This blog post is part of my new book that you can find here. Below you can get a free chapter of the book…

Email Address:

The post Rewards may destroy improvement efforts in our companies appeared first on Welcome to.

How monetary rewards destroy your Minimum Viable Product

Goals and objectives

People that follow my work know how passionate I am about topics such as performance appraisals, along with the myriad goals and objectives attached to the performance of a person. If you want to review my previous work just click here. This blog post will be fully dedicated to how goals and objectives attached to monetary rewards can jeopardise a product release and therefore a company.

Some weeks ago, I went for dinner with my friend Herman. I could see that he was worried and stressed, so I asked him: “What’s the problem? Why are you so stressed?” Herman started to explain to me that the company where he was working was going through a crisis. He told me the company needs to put a huge product out by the end of the year, or they could run into drastic problems.

I described a bunch of tools and ideas that he could use to help the company deliver a Minimum Viable Product(MVP) by the end of the year. In all likelihood, the product would not contain everything that the company wanted, but for it would certainly have the most important features needed to go live. You can begin to learn more about those ideas and tools in Vasco´s blog post right here.

Herman then explained the situation further: it was much more serious; for the new release, the product management team had dozens of KPI´s that were part of their yearly Goals and Objectives. In order to receive the bonus for that year everyone would need to achieve their goals and objectives, otherwise no one would get extra money.

Herman then explained to me that this practice could hijack the release completely. Since everyone on the product management side had all their goals and objectives attached to those KPIs, they were designing a product much more complex than a Minimum Viable Product(MVP) — All to ensure that they would get their bonus. Of course, when everyone asked them if all the features were necessary, they always said: “Of course; we cannot remove anything”.

I could not stop smiling at the situation; for years I have been preaching how Goals and Objectives attached to monetary rewards destroy companies, but now I was presented with one of the simplest examples of how goals and objectives can do exactly that. This example was so simple that even the most innocent manager could predict the outcome.

Herman knows that I am writing a book about the topic, so he asked me for some advice; what could he do? What, in that situation, would be a good idea?

So, I suggested to him what many companies already have done: Many companies used to adopt a technique where 90% of an employee’s salary was base salary and the other 10% was based on individual performance. To obtain this 10%, the individual had to reach his goals and objectives. Some companies came to understand this is more harmful than beneficial, so what they did instead was just give the 10% to employees and forget the individual performance aspect. They simply stopped mapping individual performance with bonuses.

To give another example, other companies removed sales bonuses. They simply looked into the history of each sales manager and gave salary increases to match their best bonus. When given really great base salaries, sales managers are happy and eager to help the company to sell more; people switch from closing deals to creating relationships. Before you start to criticise this polemic approach, I want to tell you that this is real, and I will have several examples in my book :)

Herman was a bit reluctant about implementing my suggestion, but he agreed that he would talk with the C level and ask them to remove all these goals and objectives attached to the bonus system.

In couple of weeks we will have another dinner where Herman will explain me what happened.

This blog post is part of my new book that you can find here. Below you can get the first part of the book…

Email Address:

The post How monetary rewards destroy your Minimum Viable Product appeared first on Luis Gonçalves.

Goals and Objectives attached to monetary rewards destroy your MVP!!!

People that follow my work know how passionate I am about topics such as performance appraisals, along with the myriad goals and objectives attached to the performance of a person. If you want to review my previous work just click here. This blog post will be fully dedicated to how goals and objectives attached to monetary rewards can jeopardise a product release and therefore a company.

Some weeks ago, I went for dinner with my friend Herman. I could see that he was worried and stressed, so I asked him: “What’s the problem? Why are you so stressed?” Herman started to explain to me that the company where he was working was going through a crisis. He told me the company needs to put a huge product out by the end of the year, or they could run into drastic problems.

I described a bunch of tools and ideas that he could use to help the company deliver a MVP by the end of the year. In all likelihood, the product would not contain everything that the company wanted, but for it would certainly have the most important features needed to go live. You can begin to learn more about those ideas and tools in Vasco´s blog post right here.

Herman then explained the situation further: it was much more serious; for the new release, the product management team had dozens of KPI´s that were part of their yearly Goals and Objectives. In order to receive the bonus for that year everyone would need to achieve their goals and objectives, otherwise no one would get extra money.

Herman then explained to me that this practice could hijack the release completely. Since everyone on the product management side had all their goals and objectives attached to those KPIs, they were designing a product much more complex than a MVP—All to ensure that they would get their bonus. Of course, when everyone asked them if all the features were necessary, they always said: “Of course; we cannot remove anything”.

I could not stop smiling at the situation; for years I have been preaching how Goals and Objectives attached to monetary rewards destroy companies, but now I was presented with one of the simplest examples of how goals and objectives can do exactly that. This example was so simple that even the most innocent manager could predict the outcome.

Herman knows that I am writing a book about the topic, so he asked me for some advice; what could he do? What, in that situation, would be a good idea?

So, I suggested to him what many companies already have done: Many companies used to adopt a technique where 90% of an employee’s salary was base salary and the other 10% was based on individual performance. To obtain this 10%, the individual had to reach his goals and objectives. Some companies came to understand this is more harmful than beneficial, so what they did instead was just give the 10% to employees and forget the individual performance aspect. They simply stopped mapping individual performance with bonuses.

To give another example, other companies removed sales bonuses. They simply looked into the history of each sales manager and gave salary increases to match their best bonus. When given really great base salaries, sales managers are happy and eager to help the company to sell more; people switch from closing deals to creating relationships. Before you start to criticise this polemic approach, I want to tell you that this is real, and I will have several examples in my book :)

Herman was a bit reluctant about implementing my suggestion, but he agreed that he would talk with the C level and ask them to remove all these goals and objectives attached to the bonus system.

In couple of weeks we will have another dinner where Herman will explain me what happened.

This blog post is part of my new book that you can find here. If you are interested in being a beta reader and provide me valuable feedback, please subscribe the newsletter below. I will keep you updated with the latest status and the first drafts of new chapters.

 

The post Goals and Objectives attached to monetary rewards destroy your MVP!!! appeared first on Welcome to.

Rewards are a great way to Punish people

Alfie Kohn, in his book Punished by Rewards, explains to us that rewards and punishments are two sides of the same coin; they are not opposites at all, and in fact have a strong kinship between them. Another author—Kurt Lewin—in his book “A dynamic Theory of Personality“, goes even further. He says that rewards and punishments are both used when we want to produce in others “a type of behavior which the nature-filled forces of the moment will not produce.”

The problem with this approach, when applied over the long term, is that it relies on us raising the stakes higher and higher to produce the results we seek; we must dish out greater threats or rewards in order to get people to do what we desire.

Alfie Kohn explains that “punishment and reward proceed from basically the same psychological model, one that conceives of motivation as nothing more than the manipulation of behavior.” If we analyze the objective inherent in saying “Do this and you’ll get that,” or of someone who says, “Do this or here’s what will happen to you,” we see that in reality, those who say such things are manipulating the behavior of others in order to get what they want. What “effective” rewards and punishments will do is to control people’s behavior, by describing what will be given to them if they comply— or be done to them if they don’t comply.

One of the biggest reasons that we can, rather ironically, consider rewards a great way to punish people is due to the fact that, with rewards, we can actually control people’s behaviors. But this facet of the situation is not the only problem—there is another, more simple and straightforward problem: What happens to the person who is expecting to get a reward, and for some reason is not able to achieve what was necessary in order to get that reward? When he or she cannot meet the necessary criteria?

How many of us can remember a situation where we or our colleagues were expecting a bonus, for example, and that bonus never came? Do you remember how you felt punished because of that? When you worked hard to get that money, but for reasons outside of your control, you were not able to get it, despite doing your best? I am sure at that point your only thought was: “Why I am not getting my bonus? What did I do wrong?” Punishment was the only thing that you felt.

In my humble opinion, this can seem like the worst form of punishment (who really feels that demoralized when unable to do something they were outright bullied into doing? Being disappointed over a loss of reward is much harder). The bigger the reward that is lost, the worse you feel about yourself.

This blog post is part of my new book that you can find here. If you are interested in being a beta reader and providing me valuable feedback, please subscribe the newsletter below. I will keep you updated with the latest developments and the first drafts of new chapters.

The post Rewards are a great way to Punish people appeared first on Welcome to.