#netlight

Gamification is a word I hear all around currently, and I like it. For me personally taking everything far too serious gamification is a great tool to stay in balance with my stress. Hopefully it will help me last a few more years :-).

In services I use I also like gamification, who doesn't want a fun user experience showing there is some thinking and depth behind. Fun doesn't mean non-professional as it used to when I was a kid - meeting greyish robot-like-people at the bank or watching the news.

But what about your own company, could it gain from introducing a little more gamification? Will it make people more engaged and involved?

Currently I hear about several companies introducing loyalty programs for their employees. As an employee you will earn loyalty points based on your actions and your result (I assume it's based on your team/group result so it doesn't make a nursery for individualism on behalf of creating together). I guess it will be used both as a carrot to change behavior as well as strengthening correct behaviour by rewarding it. Your loyalty points you can then convert to real value merchandises or services in the company internal web shop.

I can't really make up my mind if I like it or not. I like the fact that you challenge what is "normal" and that you care about your employees. I like the fact that you can promote and reward good behaviour. I love how you promote role models within your organisation and cement your values around those. That's how you build your culture - remember a company doesn't have values and culture, people do.

But what makes me hesitant is how you reward and when...and what you reward with. The risk I see is that you’re not getting the healthy incentives you’re hoping for if you don’t think it trough, so please do. Wouldn't it be better if the reward was made by the individual herself, feeling good about doing something great, and by the people close around? It doesn't really scale if somebody at top (now I'm guessing) do have to come up with anything and everything to award and how much it is worth. And what does that signal about everything that's not centrally set as "rewarding", isn't that worth anything? Should the responsible person and team not take care of those things? And who will be the judge deciding who deserves which reward? Will it be fair for all or will the situations of injustice be the ones remembered?

I just picture myself, raising up my children, promising them candy every time they do what I ask them. Yes they will probably be good children doing what I ask them, ie behave well (if they don't get too crazy from all the sugar). Or will they only learn about the rewarding game and not become healthy thinking and questioning human beings? Yes, most likely they will adapt to the system, do whatever it takes to get candy when they feel like it but never do anything else. Own responsibility?, hmm what is that?

Don't get me wrong, I love games and gamification but maybe we're simplifying things a little too much believing we can apply it directly on (work)life as a whole. For isolated areas I really like the idea as it brings an extra dimension of joy and meaning to many. Like social networks it works fine. To many it brings an extra level of excitement and meaningfulness counting your likes and your friends. But running your life only based on drivers like KPIs of likes, friends and followers will probably not be the final answer to happiness, or? Life as I know it is more complex than that.

As I said I'm not really sure what I think. I love to follow the experiment of internal loyalty programs as just that, an experiment. Implemented correcly it might be a very good thing, but what I'm saying is I see risks. I love change, I think we in our modern companies need change over and over again to make sure we challenge ourselves and keep on growing professionally and personally. I love to try any ideas that come from employees for employees since they, me, we, are our greatest and only real asset. We all, as employees, have and share the responsibility to make sure work is fun. I have the responsibility to make sure I'm passionate about what I do. Just as in the life outside work (I think it's called free time) I'm sure you're taking responsibility. I'm sure you make sure to do the things you don't like as quick as possible and spend the rest of your time on things you do like, things that you think are fun or make you feel good. Complaining? - to whom and for what reason? Of course it's good to drain your feelings to friends now and then, but complaining doesn't do any real good. And same goes for work life, I believe. Complaining I see as a sign of you failing in taking responsibility, for some reason. And it's good to understand why and do something about it - that's taking responsibility.

So, do you need to have an internal loyalty program to retain your employees? Maybe it's a good idea but please think it trough with your employees and together understand what you want to achieve. If you think an internal loyalty program is the only way to retain your employees, unfortunately I think you're in big trouble.

Anyhow, I'm very interested to see the outcome so please share your experience if you have some.

Do I think it is important to keep employees involved and engaged - 100% yes. Do I like sharing company profit in any way - absolutely. Do I think people should have fun at work - where can I sign up?

What’s your thoughts, how do you design and introduce gamification within your company to increas engagement, committment, passion and keep all healthy incentives? What's your experience of internal loyalty programs?

...............................................................................

After going arond for a day not getting the post out of my head I came up with the following idea of how to design a gamification model that might drive healty incentives and good behaviour.

What if all colleagues around you dynamically award each other points whenever they feel like you’re doing something good, something bringing value to them or others. Like a natural feedback thingie, just like you say tanks for helping or great work – may I call it “microrewarding”.

If you are engaged, if you show you care, if you take responsibility, if you have a good perspective bringing value around, if you have a big followership, if you are a natural go-to person then you will earn your points. The great thing with this model is that you don’t need a judge nor referee for the game. It will be self-managed, how life works already.

This model of gamification will probably help you better identify valuable people not only seeing the obvious ones knowing the right people or the ones in your closest network.

Scalable? Oh yes, this model will scale to infinity.

But what about the reward? I think it would be enough with the honor of being seen and promoted role model. Since the points you have will (should) reflect your contributed company value, it’s of great input during your annual salary review process. Doing a normal 360 tend to make us focus on the past month or so as that’s what we humans have fresh in mind. But with this gamification model, which more or less is a live ongoing 360, the whole period will count equally important over 6 or 12 months.

Of course the model will come with challenges; there are no shortcuts in building great companies - it’s all about hard work. In this case a lot of hard work must be invested in setting the guiding principles for how to behave, setting the culture. When and what to reward and when not to. How to treat all equal and give all the same equal opportunity despite gender, religion, skin color or culture.

Dangers? Actually, as we see with gaming, the constant rewarding and hunt for the next reward after that, might not be very healthy. For some it might become the uncontrollable heroine. But for the majority I think it would be a very interesting experiment to be part of. And I think it really will get the dialog and communication going about values, about what is good behavior and not. About how to spend your time in the best possible way. About how to take responsibility and being a role model. About how to build the great company of tomorrow.

What a an exciting and fun experiment to follow :-)

About the author

I’m Mandus Engman. I’m Partner at Netlight, I’m a Genuine Consultant, I’m an entrepreneur, I’m a father and I’m a believer. I meet many companies in different situations, different challenges and different opportunities, I meet the people. I’m a believer in the meaning I believe that together we can really make a difference. Together we can really achieve something and make the digitial future and the world a better place

    We all start there, with the famous Monolith Architecture. Why? Because it’s easy, it’s fast, it suits our needs just fine. Remember the first rule when distributing your systems – “Do NOT distribute your systems”, until you need it, then “Do NOT distribute your systems”, unless you really really really need it. So the Monolith is the perfect start for any start-up and can suit your need for a very long time, potentially forever.

So why bother understanding what Microservices is all about?

    There might come a day, when you feel you grow out of your Monolith. The size of your organization has grown quite a lot, your dev department is getting bigger, perhaps dev centers separated geographically. All you know is that growth is the only thing that will stay stable for the near future. Sooner or later I think you will start to see the typical signs of you outgrowing your Monolith (if not – congratulations, please tell me and the world how you did it); You start to realize that small changes within your intercoupled Monolith impact areas you didn’t think of, leading to costly incidents. Things are getting complex due to all dependencies. KISS becomes harder.

You realize you want to, you need to be agile, but deployment is hindering you as it takes too long time and too much effort to deploy. You can’t deploy the small parts you updated in isolation so you have to do the whole thing.

You realize there’s legacy parts of your system you don’t dare to touch, no one does, so you build around. Developing new features (business or tech) will be more and more expensive since the only compensation for you systems growing complexity is increased quality. And we all know how expensive increased quality is, both for dev in itself but also the additional QA work required.

Eventually things will in a larger extent break and you will spend more and more time on failure demand, cleaning up the mess, than on value demand, developing your business. By now your REAL problems are likely to start show and you will probably start see the frustration around. Dev will most likely get a hit on her self-confidence, the pressure from the organization will grow and the joy you used to have will be jeopardized. From the business perspective one start see things taking longer time and Business people will have to fight more and more to get their things into the three-months-roadmap. They will most likely start interfering into dev work, dev processes and dev decisions like never before. Things like mistrust, control, processes will start becoming the words on peoples lips.

Sadly this will often lead to growing bureaucracy and hierarchy; your organization will most likely become more top-driven and politics and individualism become a fact.

What it does to your previously so lively and joyful dev teams? I think it will have a great impact on the inspiration, energy and commitment of your dev teams – hurting the innovation and engagement. Unfortunately it will risk your most driven tech people, seeking new adventures.

In all together you start to realize that your baby that used to be so small and sweet, over the years has grown and become a monster, something like the famous “big ball of mud”.

So what to do, what’s the cure? Which architectural solution to go for?

    It all depends on what you want to achieve and that’s where you need to start. Telling by the symptoms above I assume what you want to achieve, I would, is for your dev department to continue its joyful and innovation-driven journey together with the rest of the organization and business. Then I believe what you need the most are;

Independent scalability

Independent failures

Independent deployment

These three qualities will provide wonderful things since it pulls out dependencies and by that removes complexity. Dev teams can again focus in isolated areas; scale, handle quality, handle failures and deploy independently from all other teams. So which architectural solution to go for? Use anyone as long as you fulfill the three qualities.

What about Microservices, could that be the solution for my organisation?

    Yes, Microservices will definetly help you support the three qualities; Independent scalability; Independent failures; Independent deployment. But Microservices will as well support you creating a new “big ball of mud”.

To me Microservices is a mindset more than anything else. Initially, being new to Microservices, you will make mistakes, no question about it, but if you’re eager to success, if you use your architect experience well in combination with a great portion of common sense and continuously seek new competence and experience from others – you have a promising and exciting future in front of you, and full of hard work. The main fundamental capabilities of Microservices and the resons to go for Microservices according to me are;

The super qualities - support of the three qualities that are so crucial for successful long-term business critical IT development; Independent scalability, Independent failures and Independet deployment.

Burn it to the ground (including your darlings), over and over again – to me one of the most important and valuable mindset of Microservices is to avoid making anything too big or beloved to mentally be prepared to burn it to the ground, at any time.

Remember the old scary legacy code in the Monolith that no one dare to touch but would build around? In the world of Microservices just burn it to the ground and rebuild it.

In the Monolith when introducing a new feature you tend to bring in the generic perspective too early, just in case because you know the code will stay around. In the world of Microservices you’re permitted to have a much more healthy mindset; don’t bring in the generic perspective (that will add complexity and extra code to maintain, ie cost) until you really need it. When you really need it, you have the option to expand an existing Microservice or to burn it to the ground and rebuild.

In our agile world the only thing we know for sure is that things will change. In the world of Microservices you can really embrace change. When the basic requirement change too much we all know it’s better and more cost effective to rebuild from a clean slate but in the Monolith you don’t always get that option, it’s too risky and costly. In the world of Microservices - burn to the ground and rebuild!

New to Microservices? Of course your services and structure will suck initially. A year later you and your organization will know so much more. Burn to the ground and rebuild!

Just knowing your Microservice can be burned to the ground and rebuilt makes you a better developer and architect. You may focus on what is important then and there. You don’t have to spend too much time weighing pros and cons back and forth regarding patterns, frameworks and tools. In the Monolith you tend to build with high quality all the time, in your Microservice landscape you don’t have to, depending of what you need to achieve.* A single Microservice is the perfect (in theory) container of coherent logic. An isolated component or system doing one thing and that thing very well.

Last words for now…

    Yes, Microsoft provides great powers and used right it could be the answer for many companies, which I see already looking at our (Netlight’s) clients. In the post, however, we haven’t talked that much about the pitfalls, which of course are many (spared for a later post, perhaps). But we should all understand that transforming your Monolith into Microservices means an enormous amount of work and something your entire organization must be involved and committed to. And be careful, designing your Microservices too small, will just move your current complexity into your integration layer. Designing them too big will divide your huge Monolith into a couple of smaller ones, still Monoliths. There is no such thing as the correct size of a Microservice, don’t believe anyone saying there is, and of course the number of lines of code is a very bad metric. What I like is the mindset that any of your Microservices should be rebuildable in roughly a month of time. Then you will still be able to burn it to the ground and rebuild when its time has come. At the speed technology, knowledge and organisations develops today, after 2-5 years I bet the majority of your complete Microservice landscape will have been rewritten. That’s healthy evolution to keep you a competitive player and a healthy company.

What’s your experience of Microservices and Microservice Transformations?

About the author

I’m Mandus Engman. I’m Partner at Netlight, I’m a Genuine Consultant, I’m an entrepreneur, I’m a father and I’m a believer. I meet many different companies in different situations, different challenges and different opportunities, I meet the people. And I’m a believer in that I believe that together we can really make a difference. Together we can really achieve something.

My purpose and passion in life is kind of three folded;

I want to be part of creating the digital future we all live in – I love technology...in combination with business

I want to find talented people and companies eager to find a purpose themselves. I want to help them reach their full potential and I want to create magic together with them.

I want to show the world that the future of high-value service companies should be based on trusting the individual and self-management rather than hierarchy and individualism.

And remember - Sharing is always caring…