Decide on your salary, or not…

Practice what you preach. As the Happy Melly One (HMO) team we’ve applied our own Management 3.0 tools, ideas, and practices. One of our practices is the salary formula.

A few years ago, when Jurgen Appelo was still the Emperor-God-Overlord of the team, we decided to implement a salary formula. After some debate, where the team discussed if they should take location, country, family size, experience, etc… into account the team decided on a very simple formula.

The maximum salary you can make is fixed for everyone and based on your Commitment Level (CL). If you work one day a week for HMO, you are on a CL 1. If you work five days a week for HMO, you are on CL5. Your CL is between 1 and 5. Furthermore, we have a fixed salary per CL. For example, 1 CL is equal to 100 euro.

The other part of our salary is merit money, a monthly bonus system based on appreciation. You can read more about that here.

We liked this approach. It is simple, fair, and 100 percent transparent. As Chad said, he can tell his friends that everyone on the team makes the same money. How cool is that?

Times Change

At the end of 2017, we had some discussions about our salaries. We were paying everyone equally so for example, our Financial Queen, Tahira, makes the same money as our Web-Craftsman Hannu, or our Illustrator Chad, or me the Chief Empowerment Officer. We don’t take into account location, experience, or anything else. Is this fair? Is everyone equally important?

We also wondered if we would be able to find new team members with the current salaries being as low as they were.

We work with freelancers and some us would like to spend some more time on our work for HMO/M30. However, because the salary is not that high, it’s a financial challenge. So the question remains, should we pay some people more than other people in order to make sure that some people can spend more time on HMO?

What to do? We starting looking around us, and I also looked at our sister company, Agility Scales. How are they approaching salaries? Their approach is that you decide your own salary. Yep, take a few minutes to think about that. Wouldn’t that be great? Decide on your own salary. Great summer holiday here we come! Team members deciding on their own salaries! I loved the approach! Why make it complex, you just decide how much you make.

It turns out this approach is not unique; there are more organizations who use this approach. For example Morning Star and Gore.

You decide

When I proposed this to the team, there was silence. The silence where you think that the video is frozen.

I explained the idea to the team. You write a salary essay with a maximum of two pages. In the essay, explain what salary you would like, and of course why. The why can be related to your location, your role, your experience, etc… Whatever you think is relevant to your salary should be included. When you have your essay ready, you discuss this with the team in a virtual face-to-face meeting. People can ask questions, ask for clarifications and they can agree or disagree. Based on the feedback you maybe need to review your salary essay. You can read my salary essay here.

Deciding on your own salary is not just shouting out a random number. With great power comes great responsibility, so you definitely need to describe the why.

For this approach to work, you’ll require full transparency and a team that dares to challenge each other. A team that feels safe, to be honest with each other and a team that is capable of giving each other feedback.

We decided to try this approach. All team members wrote their salary essays.

Firstly, everyone had to determine what kind of work he or she does. Sounds easy no? But how would you compare our Zookeeper to other jobs? How do you compare the Guardian of Content, or Facilitator’s Guardian to other roles?

Secondly, we had to find benchmarking data. For example, our Social Media Master is located in South-Sudan. Trust me, there are not that many websites that show data about how much a Social Media Master in South-Sudan can make. They have serious other problems over there.

Thirdly, when you work as a Financial Queen in India for an international team, do you compare your salary to people who do the same in India for local teams or do you use data from organizations in the U.S or do you use data from organizations from Europe?

Fourthly, how do calculate your salary when you have the role of Chief Empowerment Officer and Guardian of Content? Do you take the average?

Finally, we have the merit money bonus system where we give peer-to-peer recognition using bonus points. Do you take this into account when you look at your new salary? Do we keep this the same or do we change the bonus system?

To summarize it one word it is complex.

What did it bring us?

Nothing; Or did it?

In the last meeting where we discussed the process of salary essays, we asked ourselves as a team: What should we do next? We had three options:

  1. Keep everything the same
  2. Use the new salaries as proposed in the salary essays
  3. Keep salaries equal and give everyone a raise of 20 percent

We voted, and the team voted number three. We said no to raises of 35 percent or more… seriously some people said no!

Even our Financial Queen said we could afford to pay the new salaries. Minor detail, but important :). Some us would get a raise of 50 percent or more. Not sure what I did wrong but in the end, me as a CEO would make the least amount of money. I was, by the way, the only person who voted for the new approach.

Isn’t that surprising? So was everything we did for nothing? Was it a waste of time? Totally not! It was one of the best experiments we did in the last year. We learned a lot.

Let me explain.

First of all, everyone did some research about his or her role. We found out that some people in this world make a lot of money doing the same things that we do. That was a surprise, and some of those people are probably overpaid, but it did show that we should increase our salaries.

We realized HMO is a special team and we have some  great perks:

  • We have two in-person retreats every year, where we gather as a team. We have a great merit money system, a possible 20 percent bonus every month.
  • We don’t check on our team members, you can work from anywhere at any time. We don’t care where you work or at which time you work.
  • We have great colleagues!

Also, the flexibility is great, if you have less time for HMO next month because of other projects, that’s no problem. Just lower your CL, and also the other way around. You need to spend more time on HMO, just raise your CL. We trust each other 100 percent. Our salaries are maybe lower than what you can make with other companies, but where do you get this kind of freedom? It is something you sometimes take for granted, but by doing this experiment, the value became very clear for us again.

It turns out that we can (still) trust each other. Nobody came up with an exceptional, unrealistic salary request. Everyone was realistic and explained why he or she wanted to make the salary they proposed. It all made sense.

Why did we as a team then decide for just a raise?

The team realized they value fairness above everything. We are a flat team, everyone is the same, no hierarchies, no differences, we value everyone making the same money. We don’t want to have the feeling that other team members make more money because they are more important. We need everyone in the team to grow Happy Melly and Management 3.0. We need our Financial Queen, our Zoo Keeper, our Illustrator, our Social Media Master, our Web-Craftsman Developer, Facilitator’s Guardian and our CEO. You can write a book or song as an individual, but you need a team to make Happy Melly and Management 3.0 great!

Final Words

I know it was a long read, but it is hard to share this experience in only a few words.

If you can, try to run the experiment in your organization. It will give you so much insight.

We ran the experiment and we learned so much about ourselves and our team. It was a great experience! I am proud to be part of this great team!

Team, you rock!

This post was first published on Happy Melly One, click here.

How do your metrics help you?

I love to measure things. I can look up the temperature in my house for the last two years. Did you know it was 16.5 degrees Celsius on November 2, 2017, at 02:12 AM? I track the downloads of my book Doing It. 2736 downloads up and till 2018-05-20 7:02:00. I measure the steps I take every day, did you know I took 287.216 steps in October 2015? As I said, I love to measure things.

I hear you thinking… nice Ralph but how is this going to help me as a professional? Not. It is not going to help you. The more important question for me is, how is this going to help me as professional or person?

Silence… I don’t know. I don’t see how the history of the temperature in my living room is going to improve my life. I don’t see how the number of the steps from the past is going to improve my health in the future.

If you are a lead or manager, you probably need to create a report every week. Maybe you have automated it, and you created a dashboard. A dashboard where management can check the metrics of your team or organization. Regarding that dashboard, sorry to disappoint you, but I expect your manager hardly ever checks the dashboard.

Take a look at the report. Which data is there? Probably data that is easy to measure. Like the living room temperature, the steps I take, etc. We tend to create reports on things that we can measure easily. Often these measurements are related to output. Something happens, and some data is available. We call these indicators, lagging indicators.

Lagging indicators are often easier to measure, but it is hard to make a change in a process based on lagging indicators. For example, I measure the temperature in my living room, but the temperature is something that already happened. I can’t change it anymore. Measuring the number of new hires is also a lagging indicator. It already happened. You can’t influence the process anymore.

We also have leading indicators. Leading indicators say something about what is going to happen. For example, the temperature outside could be a leading indicator of the temperature in my living room. When the temperature outside is 35 Celsius or more, I know the temperature in my living room is also going to increase. If the influx of candidates is growing in an organization, I can expect the number of new hires also going to increase.

I will give you another example. I try to maintain a stable weight. A lagging indicator is measuring myself every day. It already happened, there is nothing I can change anymore. A leading indicator could be to measure my activities, and food I eat during the day. These are leading indicators. I know when my activities decrease, the number calories increase, my weight will probably increase.

The question is when you look again at your dashboard or report, what kind of indicators do you have? Leading or lagging indicators?

Would you like to learn more about good metrics? Join my workshop on July 3rd in Utrecht. More information can be found here.

12 guidelines for good metrics

One of the views of Marti, the Management 3.0 Monster, is Align Constraints. Align Constraints is for me about the behavior of people, but also about direction. In a Management 3.0 environment, there are maybe teams who are self-organizing, and also self-steering. These are two different things!

Self-organizing teams are common practice nowadays, definitely when an organization has implemented Scrum. As it is written in the Scrum Guide: “Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” These teams are not self-steering! They don’t decide themselves where to go. They only choose how to go, when the Product Owner has decided where to go.

As an organization, you can go one step further, and also create self-steering teams. Scary of course… how do you know they will walk or maybe even run in the right direction? You don’t, that makes it scary. When you would create self-steering teams, and they would go into a direction you, as manager, don’t like? What to do? You could step in, and order them to go into the “right” direction. However, by doing this, you just destroyed the self-steering team. It turned out it was not self-steering. You decided to step in…

If you are going to work with self-steering teams, it would be wise to implement a Delegation board. Also, understand your role as manager in the delegation board. Also, you need to make there is a clear vision and purpose for the organization. This will give the team a direction.

However, there is another thing that is required for self-steering teams. Metrics! No target-setting based on metrics, but metrics to understand what is happening.

There are 12 Guidelines for good metrics. If you keep those guidelines in mind, it helps you to develop useful metrics. Metrics that a self-steering team can use to find out where they are going and how they are performing.

Guideline 1: Measure for a purpose.

What is the reason you are measuring? Can you give a reason in a few seconds? If not you should question your metric.

Guideline 2: Shrink the unknown.

Always measure from multiple perspectives. Not just measure one dimension of a system, but try to measure various dimensions to understand what is happening in a system.

Guideline 3. Seek to improve.

How does the metric help you to improve? Is it an actionable metric? Or just a metric to make you feel good?

Guideline 4: Delight all stakeholders.

An organization is a complex adaptive system. There are many people and systems involved. You can’t please everyone, but you at least want to know when someone is getting unhappy.

Guideline 5: Distrust all numbers.

In the end, numbers are just numbers. Do you really believe 42 is the right answer? Always keeping your mind when you see numbers.

Guideline 6: Set imprecise targets.

Every process has a biorhythm. Every process always has deviations. Do you want to focus on every difference? Or just the significant exceptions?

Guideline 7: Own your metrics.

Involve the team, if possible ask the team to create their own metrics. By doing this, the team knows what is measured and will also get maximum insight into the data.

Guideline 8: Don’t connect metrics to rewards.

Do I really need to explain this?

Guideline 9: Promote values and transparency.

Make sure all your metrics are visible for everyone, but also work on values that promote correct behavior.

Guideline 10: Visualize and humanize.

Nowadays, you can create pivot tables in six dimensions, use extreme colors, almost an art itself. However, it is not the goal to use all features in Excel, the goal is to make simple to understand.

Guideline 11: Measure early and often.

Depending on your goal, you need to think about the frequency. Would it make sense to update traffic information in Google Maps every 1 millisecond, or would every five seconds also do?

Guideline 12: Try something else.

After a while, that can be any time, your metrics won’t give you any useful data anymore. The system changed, or it adapted itself to fit into the metrics. Time to change, an experiment with new metrics.

12 guidelines that can help you to improve your metrics. You will need good metrics to work with self-steering teams, to understand what is going on. These guidelines can help you to develop useful metrics.

If you want to learn more about this, feel free to reach out to me!


Wow, what a mistake we made as distributed team!

As maybe most of you already know, the Happy Melly One team is completely distributed. In case you didn’t know let me tell you about our team.

We cover four continents, five time zones, six languages, and eight people. The team, in different settings, has been working together since 2011. You can read more about our team members on this page.

Our zookeeper is Lisette Sutherland. She recently published a book about Distributed Teams. We are not going to promote the book here, but in case you are interested click here. Lisette interviewed more than 100 people. Asked them about their experiences with all kind of different setups of remote teams. The Happy Melly One team is of course also mentioned in her book.

As the Happy Melly One team, we take care of Happy Melly and Management 3.0. Both brands are doing well.

We do everything remotely and use all the best practices regarding remote working.

We always use webcams when we are in a meeting. Webcams are turned on, no discussion about that. Even when one of our team members is still in bed (and decently dressed, no worries). We all have the best headsets; we even once ordered a headset for a team member who didn’t think they needed one (they did!). We all are aware a perfect internet connection is essential.

We use the best tools available, and fit for our team. We use Slack instead of email; all information flows through Slack. Even when you have a question for one person we use Slack. We are in love with threads in Slack. We use Zoom for meetings. It is reliable and always works. When on a group call, you are not affected by the lowest bandwidth of one person (like Skype). Also, the gallery view of Zoom is great because we can see everyone on the call at the same time. We use IDoneThis to have asynchronous conversations every day. We use Bonusly and Kudo Cards to give each other compliments and feedback. We have introduced the concept of a proposal document to be able to make decisions in a distributed team. We use Google Docs for collaboration on documents. And most of all, we apply the concept of working out loud. Yes, we are definitely a showcase in Lisette’s book as proof that remote teams are possible and can be effective.

So far, so good… So what is the problem?

We did not realize that it could have been so much better all these years. This is also described in the book as a must-do and it’s one thing we didn’t do until January this year.

In-person retreats! Sorry if you expected something more shocking. It is that simple.

As I said, we all agree that remote teams can be as effective as co-located teams, however only when you realize it is not like working in the office. You need to set up extra tools, working agreements, hardware, etc.

However, getting together now and then, and looking each other in the eyes while discussing difficult topics, partying together, and being able to work for hours in a row together on a topic is important.

We believe that as a team, we made a huge step forward after our last retreat. One of the most important conclusions from that retreat, which was our first, was that we need to do this every six months.

So our next retreat will be in Dublin at the end of June. Again a weekend of building relationships, working for hours together, being able to make decisions and most of all, having fun. Last time not everyone was able to make it, we had three people joining remotely, this time almost everyone will be able to make it!

So remote teams are great, but meeting each other a few times a year makes things even greater!

Teams don’t like me as Scrum Master

It is true… development teams don’t like me as Scrum Master. They blame me, they tell me it is my fault, they tell stakeholders that Ralph the Scrum Master said it was not good enough. Probably making the stakeholders think: “Who is that guy to decide if it is good enough?”

Why do they don’t like me? Because after one sprint of hard work, I am the one who tells them that they are not allowed to show the results of their hard work to the product owner and stakeholders. It is me who is so black and white. It is me as Scrum Master who doesn’t understand that they really worked hard and even did some overtime!

Sometimes the product owner or some of the stakeholders ask me “Ralph, but why not, this seems so unfair?”

OK, let me explain why sometimes I am a horrific Scrum Master in the eyes of the development teams.

We all know these projects where the team reports 80% of the work as done, and when the software/framework is done, we can do everything we need to do, and even more. OK… sounds good, so let’s just wait until that final 20% gets done. For some reason, however, that last 20% of the work will then start taking 80% of the project time.

What will happen when a development team shows work done during the sprint that is not really done? Maybe they even say, it is not completely done. Trust me, when stakeholders leave the room, they will remember the software that has been shown during the demo. They will forget that small footnote, it is not done yet. So the impression is, the project is on track, everything was done.

The team will still need to finish the items that they showed during the sprint review (not sprint demo!) The work that is not done could pile up, and it will take a few days in the next sprint before they can start working on the new sprint goal. With a bit of bad luck, this will get worse over time, and also influence the velocity.

The most important reason I forbid teams to show work that is not done at the end of the sprint, there is no learning! No reason to improve! Scrum is for me all about making things visible, being transparent, and inspecting and adapting. If we don’t show to each other that we don’t have items done, why improve?

Let me tell you about a few recent examples, where I coached teams and made them have a bad day because of this.

One team committed to two items in one sprint. They estimated the items to be around 40 points. The team believed they were able to make around 80-100 points in a two-week sprint. I told them upfront, guys it could be smart to split up those items. Either the team was too stubborn or I did not explain myself clearly. The day of the sprint review came and I asked hey guys, what are you gonna show during the sprint review? Those two items? Are they done? Yeah, almost, 90%… Nope, you are not gonna show them. I used my veto and forbid it. The team was upset and blamed me explicitly during the sprint review. Fine, no problem for me. Guess what happened in the next refinement session… they split all big stories up into small stories.

A second case. One team had a big dependence on a visual designer. However, this person was overloaded with work and also reported ill a few days during the sprint. The team said we can show and report it done during the sprint review. The only thing we need to do is to do the styling, but we can explain this and do it next week. Well sorry again team, but you are not gonna show these items. They are not done. I would like you to report why it is not done, though, because of your dependency on the visual designer. You should make the organization aware of this problem, by mentioning it during the sprint review, and the impact, it will get attention. There was a second team who reported the same issue. The result was that the management team looked into, and started to get some extra project funding together to get an additional visual designer.

To make this all work, make sure you have a good Definition Of Done. The Definition of Done is used to decide if an increment or backlog item is done. In a very transparent way, the Scrum team should know what the Definition Of Done (DoD) is. As Scrum Master, you can refer to the DoD and not just because “I say so.”

I hear you thinking, Ralph, Scrum is all about inspecting and adapt, and you throw away this opportunity. True, I throw away THIS opportunity, but the moment I tell the team no you are not gonna show it, I also ask them to schedule a meeting with the Product Owner asap to show the progress to him. Furthermore, I advise them to have regular meetings between Product Owner and team members to discuss progress. The sprint review can and should be no surprise for the product owner.

What do you think, do teams don’t like me for a good reason?