_
RobertoLofaro.com - Knowledge Portal
Change, with and without technology
for updates on publications, follow @changerulebook on either Instagram or Twitter - you can also support on Patreon or subscribe on YouTube

_

You are here: Home > Rethinking Organizations > Reinforcement learning and gamification within the #NextGenerationEU framework

Viewed 852 times | Published on 2021-06-19 22:22:00



No, this article is not really about Artificial Intelligence- the reinforcement learning quoted in the title is really about us, humans- a missing element of many training initiatives in our certification-obsessed times.

Albeit some elements could be useful also when designing "learning" software.

This article relatively short, and but will try to aprtition its content in few sections:
_a continuous learning ecosystem
_certify cum grano salis
_continuous learning and contextualization
_what implies continuous learning (contains also a look into the future)
_learning patterns- on the ground (contains also a look into the future)
_configuring continuous reinforcement learning and #NextGenerationEU

A continuous learning ecosystem

Since the late 1990s, first with Computer Based Training, then with micro-courses on the web, I observed around Europe an acceleration in frequency, reduction in density, and minimization in both depth and after-training "settling" (a.k.a experience in application on business reality) of material.

It seems that we have a continuous learning ecosystem, but in reality we have a kind of "cost of staying in business"- which includes a continuously growing list of certifications and associated paraphernalia.

Often these amount to "sunk costs", not investments.

My first official job in 1986 was in a multinational environment that was methodology-heavy and (at least for the "main company") training-heavy.

Ditto for the second, where I was Head of Training and Methodologies, charged with the task of developing a market for methodologies and associated training and change services, and that started with one month in Paris.

Almost forty years later, I can still realize how my first two employers (American and French), with their training and induction plans, were and still are unusual within the Italian business environment.

It comes with size and territory, probably- as many Italian companies are often small and at best consider training either something that you can on the job, or something that should be delivered by somebody else before they hire an employee.


Training as an investment? Well, in a country where maintenance of physical assets and infrastructure is still elusive, imagine maintenance of "human capital".

Albeit, since the late 1980s, when I was working to design Decision Support System models and created/delivered also a training curriculum, I met companies that weren't that large, but still found useful to invest on training beyond the mere opportunistic "what we need now".

I remember more than a funny multi-day workshop that designed and delivered, since the late 1980s.

Continuous learning, in my view, is a matter of personal and organizational attitude, not of number of courses or hours per employee.

And, as will be discussed later in this article, this attitude extends way beyond formal training.

But I will get back to the beginning.

Methodology-heavy, I wrote.

My favorite, that also later adapted to facilitate the creation of Decision Support System models, was what was called "iterative development".

Or: start with boundaries and a "basement to build on", as each time you deliver a model, by using it, you learn something that actually influences further developments of the model and adjustments- faster than trying to think about all the potential options beforehand, both on what you already know (as, often, knowing something that you do does not imply being able to transfer that knowledge as a "laundry list"- you do it, and choices are "embedded" in what you do), and even more when you are trying to model something new.

At the time, as I saw in my first few projects, the standard approach was what we call even today "waterfall", i.e. one step at a time, moving just in one direction- from definition to analysis to implementation to testing and release.

In my first project on procurement within automotive, the initial budget was few thousands m/d.

I had to prepare it using the company methodology based on outputs- a case of "barrel down", as it was the fist large turn-key project: the actuals eventually matched the initial budget I had prepared, as I discovered later; not my win, just applying what I had learned in "capacity planning" for other purposes in political events and army activities, coupled with a preliminary analysis listing the deliverables, and an IT-bean-counting approach.

Despite being formally "waterfall" and "turn-key", the latter took the lead (i.e. deliver fixed deliverables at a fixed price, also if in reality, as it was something new, also knowledge of the logic of what was to be embedded within the new software evolved).

When I was eventually assigned to the key program collecting all the data from all the other sources and issuing a score, I started developing with the business analyst in a "gradual implementation", by first copying the technical analysis ("Warnier", was called back then) into COBOL comments and routines, and gradually implementing as the analysis was delivered, and adjusting based on results and improvements- gradually went up to over 10,000 lines.

So, as I saw routinely before and since then, it was always a bit of what I had learned by studying for fun about cultures, archeology, and cultural anthropology: even within a structured environment, adapt before you adopt.

The next project, in 1987-1988, was where I really felt the "multinational" side, as in Verona the leaders were mainly American, and during the delivery to the banking customer we had also contacts with our American colleagues (also because we were using a framework to streamline software production and ease maintenance, what eventually in the 1990s became a CASE tool, to generate software), while the training material to be delivered by the project included a Laserdisc prepared in... Japan.

How much multinational? Well, when I was hired in 1986, we did receive a "personnel reference binder" prescribing the dos and dontsof newly hired (partially derived from the company ancestry in audit)- in English.

When "The Firm" from Grisham was published, all that part about bureaucracy, billable, unbillable, timekeeping, budgeting up to the printing of pages with the xerocopiers by project, was familiar.

It was, actually, part of the legal framework to ensure traceability, something that much later found again e.g. within various standards as well as SOX.

And, incidentally, that level of structural traceability is still something that has to be embedded in Italian business culture, and, being treated as an ex-post (i.e. after the fact) addendum, it often falls on the sidelines.

Anyway, I saw how even in Italy since the early 1990s evolved the application of ISO9000 with similar requirements, and eventually became "embedded", not an ex-post "fix", so there is hope.

As for the training part: when I switched to a specialist unit on Decision Support Systems, I was sent e.g. in UK for training on pre-sales, and had other opportunities to attend training- we even had a timereporting code for training (I think was 580), and specific codes for project-specific training, and even codes for other time spent on business-related issues but not on specific projects (was it 590, OAT- Other Available Time? should check my payroll files from 1986-1990).

Once I was even asked to create an account from scratch (another case of "barrel down" activity), as it was considered a boring activity, to look at USA industry codes etc, and fill the forms.

Having worked on bureaucratic staff in the Army, and on library classification using UDC, I was instead fascinated at how much of the underlying culture was represented by something as simple as a classification form.

In Andersen, all units trained on and used the internal methodology called Method/1 (later M/1) and associated tools (I used Design/1 and the first version Manage/1)- it was a cross-company, cross-divisional and worldwide "lingua franca".

Or: from Turin, I could be dropped in Verona, told that I had half a day to do what my colleagues had had a week to do (read the documentation of complex project we were to help complete in a different industry), and still be able to do it.

As I would know immediately where look for what, and prioritize on the "big picture" and "first needed details", and then expand as needed on the rest.

Sometimes the administrative, technical, functional documents became a "paper mill" affair, with their dozens of commonly used codes out of hundreds potentially available (I still have booklets etc that I recycled or designed to help me speed up activities- if you work on multiple projects at the same time, always doing DSS models, you develop patterns).

My first DSS project, where I intervened at the end to produce the documentation and learn the DSS tool I was to become an expert on... had 800 A4 pages across multiple volumes and "dimensions of analysis".

I was shuttled nearby Milan on purpose at the end of the project, when it was time to complete some work, do tests, document, and then "go pilot" on few sites, before spreading across I think to remember 60+ companies of an automotive spare parts group.

As you know- I like writing, and if you already have a structure in place, it is boring but relatively easy to just structure and fill it up.

And, if you are used to be involved in routine, scheduled releases (first were press releaases and statements in politics, then all the administrative exchanges that you can imagine are incoming and outgoing in the Army whenever you have to shuttle people around, and even for routine activities and HR management), just a matter of surviving boredom.

In any bureaucracy, consistency in repetition is paramount, if you want the bureaucracy to transcend individuals, and be "scalable", i.e. expand and contract as needed.

So, I was already used to prepare a "template", test it, fix it, and then expand it (if you have 800 pages of documentation, there are obviously sections, and each section should follow a structure within the overall structure of the documentation- a Matrioska approach).

Anyway, adapting before adopting, in such an environment, should and would become a second nature, also if you were not a "natural", as I was told in London about this and other issues (my main skills on the job was to be Zelig-like: in Brussels, I became as embedded in my work environment as to eat and drink and have haircuts as my colleagues).

Hence, my skepticism to those instead seeking training and certification as "verbatim" one-off confirmation of skills transfers, and then all the CPE industry blossoming since the early XXI century, i.e. those microtrainings done to confirm that you keep up-to-date.

Sometimes I am puzzled at the material as much as at the concept, as "relevant" can be a stretch: listening to platitudes and gossip repackaged as way too often happens does not substitute use e.g. of skills in organizational analysis or project management in delivering either.

Certify cum grano salis

As I saw since 1990, when I was first hired as Senior Project Manager, often I would call some certifications results "certified naiveté" (yes, a indirect quote from "The King's Speech", when discussing the knighthood given to a doctor whose advice did not deliver the expected results).

Being certified in being able to repeat patterns because you repeated with short-term memory during a one-week (or even shorter) course is not the same as being able to adapt and adopt when and how needed, i.e. to contextualize.

The risk, as I saw also with others coming from equally "methodology-intensive" business environments, is not to use the patterns learned as additional tools, but to trying to conform reality to the learned, "reference" patterns.

What, while working around Europe, some customers called "the bubble"- consultants not embedding in the environment to deliver solutions, but trying to recycle solutions and avoid anything in the environment that could require different patterns.

My concept, both in the 1980s, when I first designed a full course (in the Army, as a volunteer, proposed an introductory course on Information Technology in 1985-1986 to escape boredom), was always to integrate some elements of "gaming"- something derived from my observation and experience when selling computer games and games consoles in the early 1980s, while still in high school.

It would be too long to explain here why- so, for now, I will share later in this article a short discussion about what I posted on Facebook few days ago.

Anyway, the key point is simple: if you add gaming, you can either simply extend replication (e.g. games that require "closed" results deriving from the loyal application of patterns to deliver a pre-defined solution), or adopt a different approach, that requires more involvement also by the training source- as those following the training and then testing via the gaming part are entitled to "adapt", and might produce unexpected solutions that have to be validated to confirm that match constraints.

Whenever there was a series of steps, this implied also adding discussion time before moving to the next learning segment and, before moving onto the next gaming step, "levelling off", i.e. having as a shared starting point in the next gaming phase somethign that was closer to the traditional "expected solution".

It is akin to a degree: if you think that you are an "expert" in something because you got a certification or a degree, then you are first and foremost misleading yourself.

You are certified as having been made aware of some patterns and associated "rituals" (documentation, lingo, processes, etc), but it is practice that turns those "principles" into reality.

Which, incidentally, will never be perfect, unless you are doing something that is 100% identical to what you had delivered before elsewhere.

Which, in turn, would be a surprising feat: e.g. a project is a project, but no two projects can ever be identical, not even in the same context.

Yes, it is one of the usual concepts that I repeat quite often: adapt before you adopt.

In my view, an "expert" has something more than the ability to replicate what was transmitted via formal training- has also the ability to spot differences that should influence performance.

What is called... context.

I studied and used in business (but did not bother to certify, while I work "by mission"- would do only if required) many "frameworks" (e.g. ISO9000, CMM, PMI, PRINCE/2, SOX, MSP, ITIL, EN27001, P3O), and the value added, in my case, has been that, since the late 1990s, instead of having to learn on each new customer assignment a different way and lingo, I was luckly enough to have to "refresh" or "get the basics on forma mentis" on a limited portfolio of elements, and adding any "local deltas", knowning that, whenever I added a new framework, there was a chance that I would reuse that later.

With a catch: as my continuous learning does not necessarily imply that I use twice in a row the same framework, since the early 2000s the chance of learning online or from digital material is that I can save the material I studied, apply it on the activity, and, if needed at a later stage, I can do what I did also with (human and IT) languages: use again the same material, but faster, to refresh.

Incidentally: most MOOCs online since mid-2000s considered that English has different variations.

Hence, also systems such as Coursera or open.sap.com "remember" your speed choices- and it happened more than once (on different material) that I followed the original material at 1.25x-1.5x (depends how familiar the material is, or how slow the teachers talk), while whenever I had to "refresh" the material could be played at 1.75x-2x (if you download the "high quality" version).

More about this later.

Continuous learning and contextualization

We humans, since we were cave-dwellers (leave Plato aside, please), became masters at adapting.

Adapting both ourselves to the environment, and the environment to us.

The forthcoming issue of Foreign Affairs contains an interesting article about Senator Fulbright legacy.

Specifically, the apparently incoherence of his stance against McCarthy, and his views on racial issues.

It is interesting the reference to what we often forget: contextualization of information, events, and, yes, people- contextualizations in various dimensions (social, spatial, in time, etc.)

Another article in the same issue tackles with what to do with our lingering COVID19 crisis, that is already spawning many "product variants", while we still have not yet defeated the original one.

The title? "The Forever Virus".

As I wrote in the past, as a consultant, I usually worked across industries, countries, technologies simply because I was called up by former customers, colleagues, or their contacts- and, generally, it was a kind of "hit the ground running"- as I had had in 1987 in that trasfer from Turin to Verona.

Luckily, since the late 1990s, thanks to the availability of relatively cheap computing facilities, I was at least able to self-administer "crash training/awareness" on technologies, business processes, and sometimes even (human) languages.

This article is about continuous learning, but I planted some "seeds" of this article both on Facebook and Linkedin, starting earlier this week.



Yes, I first read about something (e.g. on my first general ledger project asked a manager if he had a book on accounting, and he gave me as a gift a book on "ragioneria generale" from the accountant working for her mother; I had no formal accounting knowledge, only what I had overheard as a kid when my parents had a small activity producing advertisement products for insurance companies, between the late 1960s and early 1970s).

Then, absorbed from those I was working with the main elements relevant to my role (e.g. to design a financial controlling or financial reporting model, you need first to understand what it means, then what it means for your customer and the company, then apply your model-building knowledge).

While working on DSS at Andersen/Comshare in Italy, frankly my days were already long (up to 18 hours business-oriented a day, often a different location and customer or project each day), and therefore I had time to take notes, think a bit, but the few spare hours I had...

...were to remind that a life still existed.

When I left Andersen/Comshare (part of a unit called "Andersen Software" in Italy), I did not want to let go waste all that I had learned.

Eventually purchased an Olivetti M15 and various simulation games, including the one I wrote about in that Facebook post (I still have not checked if the version that I found online really works- will try, eventually).

The funny part? The game was delivered with a book and... a booklet on how to read a financial report, along with instructions on how to read the Wall Street Journal.

It was interesting to match the elements I had seen with way too busy senior managers, and then simulate across the whole product lifecycle investment and operational choices and their impacts on numbers.

Even funnier: doing some sideline thinking about "what could happen if".

My DSS models often had been mainly "reporting" or "what if"/scenario based, but sometimes some customers allowed to experiment also with the "goal seeking" features across multiple dimensions, e.g. by region, by product, by distribution channel, setting a target bottom line and stating which elements across the dimensions could be changed by the software to try to "converge".

So, I had developed some mental patterns to "visualize" models and their consequences while discussing how to design them.

I adopted the same approach later, with other technologies, methods, concepts, i.e. finding a project that made sense to me, to develop end-to-end toward not perfection, but something that now would be called "Minimum Viable Product"- but integrated with the patterns had developed, were not usable outside that "one/person contextualization".

As I already taught in the late 1980s to new members of our team, despite what they say about teaching and doing, it is when you actually try to teach what you supposedly know (or write a software implementing those "patterns"), that you actually really "fix" what you learned.

What implies continuous learning

Now, extend that method other domains, and you will get something more, that can be applied to other "project-based" needs.



There is a key element: yes, if you look at my latest CV (here), you will see that I listed also when I had a VAT registration.

It seems a quixotic choice- but, as I wanted to keep the CV short: as becoming a free-lance was not a choice- as I remembered yesterday when asked, the idea was to work few years in consulting to learn as much as I could from levels of complexity that otherwise I would not be in contact with for decades, in any ordinary company (hence, my willingness to work up to 18 hours and switch customer almost on a daily basis), and then become a cadre, eventually a manager, and help build something.

Well, it did not work that way, as you can see from the number of times when I had actually to register a VAT or create a company (and maybe will happen again few times more, in the future).

This apparent personal digression hides an element: in form, I was a contractor.

In reality, in both my first, second, and third times, I had agreed to work on any mission as if I had been hired as manager- and acted accordingly.

Which included, long before I published my first book on change in 2013, or even before published online an e-zine on change (2003-2005), as part of a plan to return to Italy (abandoned in 2005, when decided instead to try to settle in Brussels), writing routinely documents or propering assessments that shared with my customers and partners, to have some shared information, a starting point to then build on.

So much that, many times later, up until 2015-2018 (my latest multinational assignment), often suppliers and even business partners assumed that I was an employee or internal manager, not a consultant.

And, frankly, I did the same whenever I had an assignment- funny, when you have (as routinely had) more than one customer at the same time.

Consequence: continuous learning takes another dimension.

It is not just that you follow formal training when asked or whenever relevant, or prepare for a task.

Continuous learning implies, e.g. that, as my main customer in the 1990s, while living in Italy, was in banking and regularly first shuttled to Germany to meet my then girlfriend, then elsewhere, whenever I was abroad I also looked around at how banks and banking services where organized, as an ordinary customer, to find also differences and inspiration- just in case could be useful later.

Also, routinely entered offices as a customer or potential customer, and looked at forms etc, to see how similar processes were delivered in a different way- in more than half a dozen countries, eventually.

Continuous learning is not a matter of number of days per year spent into a classroom, training points scored, but of "alert curiosity".

In the background of your mind, you have the patterns from your work, and, when going around, see if some patterns that you observe (also in another industry, why not?) could be interesting, matching, different, etc.

Another consequence: I do not believe in the "9-to-5", and while in some roles went routinely over the 8 (or even 10 or 12) hours a day, when I was working across Europe and on activities where results counted (e.g. a negotiation) more than hours spent, I always found a way to carve few hours out for myself.

So, while in Paris or Zurich, found also the time to visit exhibitions, walk around, and then, in the evening, to switch places to meet new people and talk (or, more listen than talk) with unknown people.

Continuous learning requires also that: building "serendipity gaps" that avoid building a tunnel vision.

If your continuous learning is focused only on opportunistic training, you will end up either with a tunnel vision, or copying what others are doing- which means really doing what others already did.

a look into the future

We have recommendation systems everywhere- and I would not be that much surprised if, eventually, when you start asking Alexa or even just queries on google, the system were to volunteers training patterns to follow.

As I said in the previous sections, continuous learning is an attitude: would be quixotical to have all these data-centric tools around us, and not let them integrate within your own learning needs.

Actually, we already have all the technologies in place needed to do something more subtle than looking at what we are already searching, to identify knowledge gaps that could be useful to fill.

In a corporate environment, this could actually extend to advising which colleagues could be worth contacting, instead of re-inventing the wheel.

Within smart cities or other large communities with multiple actors, this could turn into an advisory system that strives to connect across "knowledge pools"- bypassing what for example in Italy are "tribal boundaries".

Obviously, the previous five lines would imply plenty of technological, legal, social changes, in order to implement something viable.

Learning patterns- on the ground

In our data-centric society, the "configuration" of your business will probably see evolve revenue streams that you did not even imagine.

In my routine webinars since the start the first COVID19 lockdown in March 2020, I had the chance to "attend" events that I would never have been able to attend if I had been working normally, and if attendance had been feasible only in person.

So, if you were to have a look at my persona agenda on Google (maybe one day will share it), you would find times when, in the same day, beside the obvious costs issue (online, for now, many events that involved costs are free), I was at the same time in different countries or even continents (virtually), or spent the morning in Germany and Italy, the afternoon in UK and USA.

Another element that you would find is the span of subjects and industries.

My aim was to focus on updating on industries and domains I worked in, now that I had what (already in February-March 2020) saw as at least one year- the on/off lockdown.

Specifically, for my potential roles in cultural/organizational change (that, in my view, include the PMO roles that I have been allowed to work on since I had to return in 2012) and business number crunching.

With an added element: expanding my passive skills on business German while updating, i.e. updating or expanding knowledge while also adding German language sources on the same material (thanks, Xing and CloudExpo in Frankfurt, for organizing many webinars, workshops, etc- while the Swiss Pulse allowed to keep seeing how the German Swiss market evolved during the crisis).

Therefore, I spent time on:
- future of banking and finance as well as controlling
- future of automotive and manufacturing 4.0
- sustainability, including ESGs (as an evolution of financial reporting)
- evolutions of business intelligence, KPIs, applied artificial intelligence
- last but not least, data-centric society, smart cities, data privacy (worked on that too).

In part was to update, in part was to keep used to working on multiple dossier, as I have been used since the late 1980s.

Which, incidentally, is part of "thinking systemically" (along with "adapt to adopt", one of my often repeated concepts).

So, it is just a fortunate convergence that all those subjects are becoming so intertwined that no amount of "vertical expertise" is and will be enough to seize opportunities.

It was already clear in 2012, when, upon re-registering in Italy and starting again to work here full-time, I also attended workshops in person in Turin, Milan, London, Frankfurt, and remotely elsewhere, and saw how the same patterns were times and again presented as a "novelty" by experts too used to work in a "vertical" industry, simply because they did not know what happened in other knowledge domains, and were used to communicate and "exchange ideas"... only with their peers in their own industry (or even sub-industry).

Incidentally: on my CV you will find plenty of industries (on page 2), but you will not find another industry that is actually a kind of "backbone infrastructure" in our data-centric future: telcos.

Yes, as member of IEEE 1997-2018 (initially as an associate, then as member in few countries), I actually had quite an observation point on technological and engineering trends and their impacts- across industries.

My first real activities for telcos were almost two decades ago, for a feasibility study on a data warehouse of "prices"- to track offers, their timeline, and optimize new offers (I had had some minimal activities before, as only with privatizations in the 1990s in Italy there was a "telco market", before it was just a monopoly).

Then, while in Brussels, as I wanted to settle there, and there had been some disturbances and issues that made not possible to keep doing my work, did two unusual (for others, not for me) steps: adapt before you adopt.

So, purchased a series of dictionaries of Dutch toward each one of the other languages I had some command of (including Latin)- to adapt, as I saw that, whatever they said, in the end, any interview for managerial or potential managerial roles in Belgium in technology and banking ended always up have or have not fluent Dutch skills (well, eventually saw that that was an excuse, after I was challenged by a recruiter "to at last show you are willing to learn it"- and passed the A2 in just one month).

Registered with Actiris in Brussels, as an opportunity that was offered was to obtain I think 60 hours of personal training on Dutch if you passed A2- which, courtesy of my early 1992 attempts at Dutch.

In 1992, I had accepted to leave my French employer to become Financial controller for the Italian branch of a Dutch-French group, and eventually to move to The Netherlands- a change in contractual conditions at the last minute, when I was to sign with HR, made me turn down the offer, but stayed on as a missions-based consultant for the CFO/COO until 1997.

So, over 15 years later, courtesy of my rusty German, it took just one month to pass the A2 in Dutch.

A SNAFU: you needed to have a contract of at least 6 months, or to open a company, to receive those 60 hours of personal language training- the latter had been "pending" for a while, courtesy of a local office in Schaerbeek that apparently did not find my Italian high school and did not consider my prior VAT registrations in Italy and UK, and for the latter...

...ended up asking again an Actiris-related office to "scale down" my CV, so that I could be hired by a call center (the alternative was a library), where I could keep being "on the technical side", exercise language skills, and, if I had eventually a 6 months contract, could boost my Dutch.

Well, stayed in 9 months, but it took only few days for seeing that I started being switched between roles- and I learned first-hand that hiding skills and experience is not so easy.

As for my Dutch... my first choice after passing the exam was to expand my skills, so, as I found that there was no available recent Dutch grammar in Italian, asked permission to the author of Dutch grammar in English to... prepare its Italian translation- it was an interesting exercise (you can read the draft that I prepared in slightly over than a month between June and July 2009, and revised in September 2009 in this directory- maybe one day, if needed, will prepare a new version. Incidentally: I transferred the rights to the translation to the original author, if you find it useful and want to share a contribution, look for dutchgrammar.com- back then was 9 EUR).

The upside? I adapted to all the changes, e.g. some long-times complained that they could not get through with the shorter time available to solve each issue, and was able to work also on other areas (e.g. business contracts, the call center side, learning along also the processes involved, the unbundling of network and service, some software tools, traceability issues, etc).

Interesting to see from the inside how a call center worked, the administrative and service issues, and how some processes could work- in the past, I had only been on the negotiating and kick-starting side to outsource a call center for a customer, or to provision, but working from the inside gives a different perspective, moreover in a multinational environment (it was in Molenbeek, an area where the density of immigrants was so high, that on Fridays there were some going around "suggesting" to shop to close down), e.g. on data privacy and data security across the customer lifecycle.

The real upside: I was rethinking to that 9 months experience recently, as that experience has been useful since 2012 when dealing with call centers in Italy (and also to set up or revise some support processes in Italy).

a look into the future

The more we increase the deployment of high-speed data networks, the higher the volume of data generated and consumed daily by people, the larger the number of sensors scattered around us, and...

... the more, instead of physical shops with people, we will have to deal remotely with suppliers, including if you consider that most shops belonging to large chains will eventually go the Amazon stores way, as already since few years ago, even in stores focused on specific products (electronics, books, etc), the staff is increasingly less and less able to provide advice on what they are selling.

They are there just to take care of products logistics within shops, and therefore it is to be expected that, to provide product advice (to differentiate shops), gradually shops will have even less staff, will become even more automated.

So, maybe, taking a page from consultancies back from the 1990s, a small team of experts (maybe even actually belonging to the supplier), will provide product advice to multiple shops, even from competing chains, and pay a small fee for each advice request that is transferred.

Because, as I said in mid-2000s while negotiating to outsource a call center for a customer, and confirmed by working on the other side of the barrier, I think that "first line of response" call centers should be answerable directly to those that provide the product or service: the information you get from your potential (the "advice" case) or existing (the "support" case) customers, in a data-centric world, will need to arrive unfiltered to those who can make sense of it (e.g. to impact on products and services).

Which is, apparently, a lesson still not filtering up in some companies, that replaced the human filters of outsourced "filtered" call centers (i.e. reporting only by exception) with bots that force customers to streamline what they say or want according to... the bot ability to understand.

Configuring continuous reinforcement learning

There will certainly be jobs that, in the future, will have a continuous, predictable training path.

And a predictable curriculum for continuous learning.

Except those that require interactions between humans, or a level of dexterity not yet available to machines, unfortunately most of those predictable roles are bound to disappear.

Call any call center- chances are, that for most administrative processes, you will not interact with a person, but with a bot.

Yes, a bot is cheaper than a human call center outsourced to a company that delivers call centers even to your competitors, so you can both reduce your costs and avoid that your differentiation level will be zilch.

Nonetheless, bots are popping up on websites, phone call centers, etc- and increasingly are becoming as annoying as the old "paper clip" within an old version of Microsoft Office.

Few years ago, actually switched a telco supplier as their automated services solved nothing, and there was no way to communicate to solve fast an issue.

Recently, not for myself, I had to deal with another telco supplier in Italy through their call center- even worse: a system that sends you back to itself is quite interesting.

In the future, more interactions with public authorities, suppliers, even devices and infrastructure will probably imply dealing with something akin to the new type call center: full automated, but involving multiple suppliers.

Already we are seeing with the "green certificate" (the EU-wide "pass" linked to COVID19) some issues about multiple channels of access, distribution, updates, etc.

Will be an interesting case study from July 1st, when it will become fully operational across the EU.

If you read the previous sections, you saw a list of knowledge domains that are more or less converging.

What will be needed is adapting- continuously.

And this will imply that we will need to ensure that "human capital" will be able to contribute not to what was pre-planned, but to change.

A logical consequence? We need a way to ensure "emergence" of human capital where is available, not just continuity.

Within the European Union, we are now in another phase of the #NextGenerationEU - this week the first four evaluations (Denmark, Greece, Luxembourg, Portugal) were released.

The four tag clouds that follow represent the "Analysis of the recovery and resilience plan" from the European Commission staff for each country.

The caption under each tag cloud? How often the word "learning" appears.


Denmark: 4


Greece: 16


Luxembourg: 11


Portugal: 13

Overall, the theme "lifelong learning" is quite common, but before writing commentary on those documents, I will wait for the other assessment reports.

I will do an exception, obviously, only for the Italian PNRR, as it is part of an ongoing publication.

Anyway, the title of this section is about "configuring" not just "continuous", but also "reinforcement" learning.

There is a reason, obviously.

Just yesterday in Italy in a webinar about the future heard again the usual idea: not that we have to focus on developing human capital wherever available, but that if parents assume that their children would not have the abilities needed to go further in their studies, they should divert them to vocational studies or practical activities.

The concept seems neutral, but obviously there is an issue: what we are talking about #NextGenerationEU, digital transformation, digital divide, etc, we are talking about a data-centric society, and in a data-centric society "human capital" does not work by inheritance, but by access.

When I was living in Brussels, attended few workshops from the European institutions about e-democracy and overcoming the digital divide: as "social cohesion" is neither cheap, nor easy, nor a one/off affair.

Unfortunately, as I saw since 2012 when I returned in Italy, it seems that many are still following the 1960s model I heard about decades ago as a kid: the "liceo classico" to prepare politicians and leaders, the "liceo scientifico" to prepare generals and top ranking bureaucrats, other high schools to prepare "technicians" that would become "cadres", and then vocational schools, or studying up to 14 years old.

I attended the "liceo scientifico", where we studied Latin, a foreign language (French, in my case, albeit I had also a bit of English, 20 hours one year and another 10 the following year, as an afternoon experiment), philosophy, history, natural sciences.

As I was interested in politics, law, comparing the Italian Constitution with others, and other "extracurricular subjects", I was asked why had I chosen the "liceo scientifico" instead of "liceo classico".

Frankly, I always found silly and outdated any form of partitioning by "background", or "manifest destiny".

Because, in the end, stating that parents should identify if their children should not study, is exactly the opposite of what is routinely done in Italy, where anybody who can afford it, if their children are unable to study, finds support for them.

Moreover, dovetails with what I heard years ago in another conference, where somebody said that that the children of workers and servants wanted to send their children to the university was a waste.

Many years ago, while I was working on cultural and organizational change for a banking outsourcing, I was asked to help with a school that had been created with just the opposite purpose: remove the glass ceiling in society, and helping the children of peasants who had the abilities to have an opportunity to do something more.

Which, incidentally, would benefit both those individuals and society.

One element was curious: some students had an issue with their parents, as they did not understand why they spent so much time studying, with other consequences.

Another example: while I was in the Army, volunteered to create an introductory course on information technology, but not just as users- as programmers.

It was interesting that, due to the success of the concept, I had each day, after my office hours, classes first with conscription soldiers, then NCOs and officers (up to Lt Colonel), each day from 4pm until 8pm (I had a 15min break at 6pm for dinner).

In the mid-1980s, a tiny slice of the population had a university degree- and STEM studies were even less common than today.

My course involved people with all levels of formal education- from elementary school (which, many years ago, was divided in two cycles), to middle high school (roughly 10-13), to junior high school (14-15), to high school (either 2 years or 3 years, the latter giving access to university), to those with a university degree.

One of the best students was a young conscription soldier who had studied only up to the third year of elementary school, and had worked as a bricklayer, I think from Sicily.

He was really smart, and while sometimes he had issues with reading comprehension as he lacked the skills, when explained, jumped forward ahead of all the others.

Eventually, some "politics" obtained that for both him and another student within the soldiers, a kind of official diploma was given, closer to what was given to NCOs and officers.

I was told that this had enabled him to get a job involving computers.

Another example: when I was in Germany in the early 1990s, I was told that some families still considered "normal" that girls study only up to high school, enough to be able to help their future children in doing school assignments, but not to attend university, and that choosing which path (university or stopping earlier) was actually done when children were really young.

So, it is also the educational background of the family that directs prioritization toward studying or doing something else.

Therefore, an apparently "neutral" statement, such as asking parents to clip their children academic wings, implies something more than a simple "objective choice".

If we talk about continuous, lifelong learning, we need both to consider retraining of adults, as many do, but also to level the playing field.

I do not plan to ever retire, just to change the way I work.

But those younger than me will probably have multiple "careers" across their life, and therefore would need to be able to switch- which implies giving them at least the same level of "learning to learn" abilities that I both acquired and was given.

As 99% of what is on my CV was never learned in my formal studies- was mainly a consequence of work, or a personal choice, a choice that I would not have been able to do if I had not been exposed to the options.

I remember many years ago what an American colleague told me: at the beginning of the PC revolution, somebody proposed to teach that subject too in school.

The issue was: not all the families could afford a computer.

Their choice? Not to create separate classes, but to provide access to a computer to all the students.

Italy is already country where nepotism and "tribalism" produced significant damages for decades, as witnessed not just but the national debt, but also by the general structure of society.

Using the #NextGenerationEU as an excuse to reform the educational system, so that it crystallizes the same tribal and social glass ceiling, would be the best way to waste resources, without generating the capabilities that will be needed in the future to be able to reconfigure the socio-economic environment when needed.

Frankly, the debates I heard in Italy since 2012 sometimes remind me of what I was told in the late 1990s in Baltic states about the policies to remove local potential alternative élites.

Or what was said to be the plan of the WWII nazi regime for Ukraine, once conquered, i.e. to lower the educational level to elementary school or whatever was needed to have workers and those coordinating them, but neither a local intelligentsia, nor a potential local political leadership.

Luckily, we never that model implemented in Ukraine or the Soviet Union, as WWII ended in a different way.

But we have seen examples of the results of artificially trying to engineer a manageable ruling and administrative class: in former European African countries, that we routinely called in the past "failed states".

Let's hope that #NextGenerationEU reforms will be used wisely, not to rebuild an Italy as it was a century ago.

Continuous reinforcement learning implies not just adding more courses, or routinely retraining, but also implementing measures to both have that training or retraining be useful, and, as we cannot know in which direction our data-centric society will evolve, ensure that, whenever there is a change, the best "human capital" is involved.

Stay tuned to see if the thinking will be systemic, or if we will return to parochial/tribal thinking.