The Technical Adventurer

You know how the saying goes: Born too late to explore the world, born too early to explore the universe. But does that mean that our generation really doesn’t have adventures waiting for us? Well, maybe not big, earth-shattering discoveries, but let me indulge in a thought experiment that could make us feel like trailblazers and pioneers again.

Where it all comes from

A few weeks ago, I had a profound realization at work. After working with the company for four years, I finally found a like-minded soul. Not to say that I felt like a stranger all the time before, but since I left university, I had the impression that the drive, motivation and fervor for work quickly subsided, as soon as somebody found a permanent position in a company. And I pitied that situation. I was always driven to explore, to find new things and go beyond the routines of my day job. That’s the reason why I indulged in my own research on process simulation, but it was hard for me to find like-minded people who would and could discuss such topics with me. Even when I went to academic conferences, it was always perceived as a quirk, that somebody would spend so much effort on seemingly esoteric topics, if he or she was not doing it for the sake of a PhD thesis.

In November I was contacted by a colleague who introduced me to a project team that was looking for a software engineer, who could help them develop some kind of machine-learning based soft-sensor. Reluctant at first, I gave that project a try and committed a few days of my time to a development sprint.

And this experience changed me. First of all, I saw agile project management in practice, and secondly, I met somebody with the same drive, motivation and technical affinity. At this point I knew: I am not alone in this company. There must be more of us.

If we only could improve communication and discussion between like-minded spirits at our companies. Then I remembered my experience with gamification during university, and how it could increase engagement and motivation. A quick search brought up a slew of articles on that topic that inspired me to write up this article.

In this interesting Medium article Anadea, a software company with experience in gamification offers valuable insights into the benefits and risks of gamified employee engagement programs.

In this blog article another software company specialized in e-learning mentions some real-world examples of successful gamification-based applications.

In this guide the author explains the different motivations people might have towards gamification, how to engage them best and how to make a gamified experience a success.

Ok, enough of the preface. With our knowledge of gamification refreshed, let’s go right into the heart of the article.

A balance of the forces

Large companies tend produce a kind of worker I would call the administrator. The administrator is content with the status quo and the established technologies and work procedures, once he has learned them. Administrator personalities are great for a company, because they thrive on routine and make sure that everything runs smoothly. But there is one thing that administrators do not like: disruption. Once they settled down, they would like to continue doing their job for as long as possible, and won’t be disturbed by a new software roll-out, fancy new working methodologies or any innovation that is outside their special field of expertise.

On the other hand, we have a few people I would call innovators. The innovator is driven by a passion to change, to renew and to bring new technology into the company. She most often comes from an academic background, but this is not a must. The innovator thrives from intense projects, on which she can focus her full concentration. But the innovators greatest bane is upkeep. If the company cannot provide systems to take over the solutions generated by the innovator, she is forced to maintain them for much longer than her passion dictates. When that happens, the productivity of the innovator falters because she needs to spend so much of her time maintaining all the solutions that she helped implement. Over time, she might even evolve into an administrator-type personality and be content with keeping alive her past successes.

To be totally clear here: I believe a company needs both personality types (and probably way more administrators than innovators). Both forces need to work together in a protagonist/antagonist feedback loop for the company to thrive. The innovators need to push the company forward, whereas the administrators need to make sure the solutions are correctly implemented in the company.

With the introduction and nomenclature finished, let me present the core thesis of this article:

If companies created systems that incentivize bringing innovator personalities in contact with each other, and presented them with challenging technical problems that they could pursue on their own motivation, the resulting pooling of highly motivated talents would bring great productivity gains and higher project success rates.

Some companies have structures in place that might be called “internal startups”. In these programs, self-assembled teams from the company can pitch project ideas that after a series of evaluation and filtering steps are supported by the company for a limited amount of time.

What makes these kinds of programs problematic for me, is one fact that I have seen over and over again: Tech people make horrible business cases. Sometimes we are enamored with a certain technology, sometimes we just don’t know about the market-related implications but in my experience, most of the time, a technology-driven project has dubious business performance at best.

So, what can we do about this? My proposal would be to separate the tasks and let those people do them best who are naturals for the job. Let business owners (or their proxies) define the business case, make them public for the company, and let the innovators organize themselves across organization boundaries to form the best interdisciplinary team.

The gamified project workflow

In my vision, the company would create a “bounty board”, where business owner would describe the technical problems they are facing in their responsibility:

• a heat exchanger that is fouling since years,
• a cooling water network that has grown so complex that nobody understands where the water flows,
• a distillation column that oscillates wildly and cannot reach its full capacity.

It is important that each project has a real business value and enough background information will be provided to the prospective team that they can start right away.

Innovators would watch the ”bounty board” in search for new technical adventures. Once they have found a proposal that fits to their field of expertise and motivates them, they must be able to find other people with relevant skills in the company and invite them to the team. Once assembled, the team would prepare a pitch and present it to the business owner who would then decide if the team should continue. From that point on, any kind of project organization can be used, but I would argue that agile methods are very well suited for such projects (small team size and limited scope).

When the projects are successfully carried out, records could be added to the personal work history of the team members that represent certain skills, technologies or personality features that were crucial in the success. In gamification theory, these tokens are sometimes called awards, badges or achievements.

In the end these tokens serve a dual purpose:

1. to remind the team members of their past successes,
2. to make the skillset of a person much more visible to other people in the company, for example when suitable talent is searched for in an upcoming project.

Rules of Engagement

Any gamification-based system needs to follow certain rules, first of all to protect innovators from veering of too much into the fun side of exploration and to make sure that a tangible benefit exists for the company. From my point of view, the following points are crucial for such a system:

1. Projects must come from the business
   I have seen enough tech-driven projects to understand that they typically do not fare well in an established enterprise. A new technology must demonstrably solve a concrete problem before administrator type personalities are convinced to integrate it into their systems. If the problem comes from the business itself and is recognized as such, the chance is much higher that the solution will be accepted.

2. Solutions must be pitched to the business
   To coordinate the effort put into the project it cannot be allowed that anybody can select a project on their own and work on it without any supervision. At the minimum, the team must propose a pitch with a feasible technology and give the business owner the chance to decide if that solution could reasonably be integrated into the existing infrastructure. Once the owner gives the team a go, the project must be marked on the “bounty board” to indicate the status to other teams looking for a project. This makes sure that only one team can work on a single project at a given time.

3. Only one project at a time for each person
   While it would be an interesting organizational experiment to have dedicated “technical entrepreneurs” in a company, in reality we all have jobs already with a certain day-job time commitment. To make sure that these duties do not suffer from the project activity, one person can have at most one active project at any given time point. From my experience, diluting the attention too much results in less productivity overall and should be avoided.

4. Support from the manager
   Time allotment and workforce planning is the domain of the manager. As such, she needs to be made aware of any project activities and she needs to approve of such activities. She might have knowledge of upcoming official projects that are not announced yet and needs to reserve manpower for that purpose. As much as it might hurt to be declined the opportunity to work on an interesting project, innovators need to accept that business needs overrule their personal pet projects.

5. Measurable progress
   While a certain amount of dabbling and experimentation can be accepted, the teams should be skilled enough to provide tangible results quickly. For example, when using an agile approach for project management, the minimum valuable product, or product interval should be clearly defined together with the business owner, who assumes the role of the stakeholder.

Summary

In this article I outlined a system which could enable a company to identify highly skilled and motivated technical people inside their workforce. By offering self-selected projects the company could increase engagement and motivation even more. It could help engage innovators as they could select interesting projects suited to their skills as a diversion from routine day jobs, and would free administrators from the burden of finding new solutions when they are satisfied with the status quo.

These projects might not be perceived as tasks or jobs, but personal quests, offering an intrinsic motivation to the technical adventurer.

The act of making technical problems explicitly visible inside the company has two side-effects:

• Firstly, it would require a paradigm shift in openness and trust, as currently not every business owner would be happy to share all the small, recurring technical issues that plague their operation.
• Secondly, solving all these issues could increase motivation across the company, as employees would get the feeling that the situation gradually improves.

Smaller, self-assembled teams increase the agility of the project and lead to higher satisfaction with the job, as long as the teams get the necessary support from the relevant infrastructure organizations (e.g. IT/OT). Additionally, interdisciplinary teams lead to diversification in skill sets and increased collaboration within the company.

At last handing out tangible achievements, badges and awards to successful employees increases employer branding and employee loyalty, especially when considering the current demographic shift and accepting the (gamified) culture that future generations embody.

Written on January 4th, 2020 by Jochen Steimel