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?
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.
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.
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:
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:
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!
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.
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.
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!
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.
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!
The title of this blog post triggered you: Either you agree, or you disagree.
Let me first explain in a nutshell why you need agile, and then how it relates to HR.
I have a background in software development. Many frameworks in software development assume they can predict the future. In other words, they think projects can be managed entirely by making big plans, introduce hand-over moments, etc.
In the nineties, we had the Software crisis, the software was always too late, and quality was too low. The industry had to do something. There were two ways to go: one that would introduce even more frameworks, steps, documents, etc and the other is what we now call agile. To me, agile proved about realizing that you need to use an empirical approach to manage complex projects.
What makes those projects complex? I could name a wide variety of things here, but one of the most important factors is the fact you work with people. You simply can’t manage people like a machine. Nowadays we call this management 1.0, and you can read all about it in the works of Frederic Taylor.
In my career, I worked with many people from Human Resources, Human Capital and probably there will be more different names for this department. I don’t like it when people talk about ‘human resources’, but in this blog post, I will refer to HR as the organization who in most organizations needs takes care of hiring, career development, salaries, firing, etc.
All those organizations had one thing in common. They worked with corporate models for personal development and reviewing people. At every organization, HR created a framework to help people grow and to help managers to review people. In most cases, HR headquarters created it, sometimes assisted by a fancy consultancy company. The HR department then would develop this model further for all employees, and because they realize they have different functions, they described a lot of skills, competencies, levels, etc.
When we execute technical projects, we use an empirical approach. We are transparent and inspect & adapt. We understand that we need to be flexible, that we need to embrace change and realize that every project needs a different approach. We come to understand that there is no magic approach that will solve everything.
So why does HR still believe that they can develop a framework that can cover everything related to people? Why do they develop one size fits all frameworks that all departments need to use? Why do get agitated when a manager decides to disagree with the HR model?
I think the time has come for HR to use a different approach.
HR has a lot of knowledge about local employee laws, skills, competencies, and people. I am not saying they are prutsers. Definitely not! I am just saying they are using the wrong approach.
Why not create some guidelines, or principles on what you expect managers or teams to take care of? I think it is very useful to use a model in some cases. Nothing wrong with that.
HR should ask teams and managers to think about how they are going to help people develop themselves. They should offer their expertise when asked for by teams, tribes or departments. They should give teams and or departments the freedom to develop their own approach.
Isn’t this very ineffective or inefficient you may ask? Perhaps, I am not saying you should not talk to each other and learn from each other. However, I believe it should mostly be a bottom-up approach. When a manager does not know where to start, HR should definitely help that manager. They should help the manager develop a framework that fits the manager’s department or team. In doing this, there is nothing wrong to be inspired by frameworks that are used by other departments or teams.
So why is HR not doing this?