organisation

The one trick pony syndrome and shorter shelf-life of knowledge

Posted on By Koenraad Seys
Attracting talent with efficiency in mind may back fire on the long term in a context of higher flux and need for differentiation based on innovation, evaluating the need for specialisation.
When looking at the majority of recruitment advertisements for both in-house and freelance jobs a lot of attention is given to experience. Focus is on acquired experience and tasks well performed in the past by the job candidate, on efficiency and specialisation, confirming the key of modern organisations operating as a well oiled machine. Once on the job, focus goes to a particular job.
This is stressed by the tendency for specialisation and the related engagement of specialised freelance or independent workers, staying only a short period until the job is done, acting in multi-disciplinary teams. This agile or ‘lean’ talent is pushed for specialisation and specific jobs where the experience obtained is repeated at every engagement. This however may lead to narrow mindedness and lack of oversight or even sense of overall purpose. As is illustrated by the banking experience. Now that the need for innovation and customer orientation is increasingly central to the success of a product or service, specialisation will hamper the definition of a broader answer to a customer’s need.
In an economic environment with the instability we know and a growing life expectancy this model may not be sustainable in the future.
The average life expectancy in the Western world hovers around 75-80 years and is expected to continue to increase. Higher education levels make that we spend more time at school. Depending on the education culture more people are coming on the labor market at 23-25 with at maximum student working experience. Under pressure of previous economic downturns and the need and/or will to mobilise youth, retirement age in Western Europe came earlier, in the late 50s on even 50 or 55. This leaves us with 25 to 30 years of economic activity and about 55 years of economic inactive life, of which some 30 years living of state pension or retirement fund. In light of the increasing percentage of elderly, this places an increasing burden on a decreasing group of economic active of which a part will be involved in the care for the elderly. They will have to provide for the funds needed to support retirement pensions.
Added to that, figures of Forbes, McKinsey and Oxford university indicate that the top jobs in demand of 2010 did not exist in 2004 and that nearly half of current jobs are under pressure of automation. This would stress the shorter period of economic activity.Screenshot 2020-09-14 at 15.33.29
Looking at skill deployment and the structure of job groups it is remarkable that most of jobs are generational. A job is learned in school or shortly after graduation. New disciplines or new jobs get introduced together with new groups of graduates. It is commonly held that you will continue this job until retirement or when it goes out of demand. Given evolution of economy, technology and the job market the latter is increasingly the case.
In the context of an increasing shift to freelance employment participating in specialist tasks as they are engaged by companies on project basis, seems to lead to a dichotomy in the work force. The company manages direct employment contracts with management and coordination profiles. Technical specialists are engaged from an increasing pool of freelancers, consultant and temporary working via agencies. This may result in increased agility on company level and the products or services provided, but it risks to be at cost of organisational sustainability. This trend is in line with increasing specialisation, due to technical complexity or driven by efficiency.
The one trick pony syndrome or at least the expectation of people hiring somebody for a specific task or skill and being convinced that this is and will be the only trick the hired person has on his sleeve is untenable for the future society. Can we permit people having ever shorter careers. In light of the economic and technological evolutions and the concept of stable specialisation (as described above), it is to be estimated that the active period of an employee, freelancer or independent professional is to end far before they come to the age of 50, leading to an active life of less than 20 years. Even when society manages to have enough income for its citizens not to work and provide us all with a basic income, the psychological need of being busy and useful will result in a need for successive re-skilling and learning.
Shouldn’t we be looking at more agile talent as advocated in the HBR interview with John Younger leading to more sustainable organisational, company or team agility. Engage the people that work for an organisation and focus on skills and competences will lead to longer relationships regardless the contractual relationship. People are involved in tasks that evolve with the needs of the organisation and its customers. They need to adapt and learn through time responding to contextual needs.
In their article ‘How Work Will Change When Most of Us Live to 100’ Lynda Gratton and Andrew Scott  paint a picture of life where we go through as a succession of working and learning periods. After a few years of career we re-enrol to school, college or university to learn new things. The structure of a linear life of growing up and getting through school by the age of 25, working and then retiring will cease to exist. It certainly will have an impact on the definition of wage  and career policies and perceptions but also on recruitment and the way we organise and fund education.
Structured education as presented by schools and institutions will and already are not the only sources of gathering knowledge. Already, new skills and trends are not exclusively taught at school. Continuous learning through interacting and observing the environment where we live in, is a corner stone we should look for when staffing organisations and jobs. Experience still matters but will be much less defined by ‘having done the job for a number of years’ and more by being able to englobe experiences and bringing them in the job at hand. A focus on underlying skills and competencies to adapt to new situations and the capability of incremental learning will (have to) end up weighing more. The availability of different learning experiences and possibilities provided by the employer will be included in the evaluation when choosing whom to work for in a still tight and maybe even tighter pool of knowledge workers and professionals.

The meaning of Minimum Viable Product (MVP) as part of the product release cycle

Posted on By Koenraad Seys
The notion of building a MVP or minimum viable product often pops up when planning software implementation or development projects. Although it not an inherent part of agile approaches to software development, it is often cited as a means to come to a quick delivery.
In my opinion the idea is rarely fully embraced or followed, maybe related to connotations related to the word ‘minimal’ and it’s echo of insufficient, crappy or a poor excuse for not wanting to invest sufficient time and means to come to a full featured product. Majority of project owners rather want to consider it as a first release of the product they had originally in mind, being fairly full featured and complete.
Is it possible to apply a MVP approach in all circumstances or should we reconsider the positioning of a MVP as part of a project approach?
A MVP can be produced for any type of product, being it a physical product or a service provided to a customer base. The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time. The minimum viable product lacks many features that may prove essential later on. (Eric Ries in the Lean Startup p. 77) Thus it serves the needs of the users/customers and is the first step in a journey of learning and fine tuning the product. In this way it certainly fits the design thinking approach where it can prove to be of better service than the prototype as the MVP is put to the test in a real productive environment interacting with the intended user/customer.
Based on this description of the MVP it is ideally fit to be applied in a green-field, developing a new product or service. Based on a conceptual understanding of the needs of the intended customer a first basic version of the product can be put to the test, seeking feedback, while already earning some income through the new service or product that is ready for a ramp up based on the feedback provided by user interaction and interaction measurement. The learning based on the first use of the product can and should then be transformed into new product feature, for which the demand is clearly demonstrated, new product ‘behaviour’ or configuration conforming the wishes and needs that have be tracked based on use. Therefor producing MVPs require the courage to put one’s assumptions to the test.
The MVP is often positioned in larger organisations. However, it does not succeed in delivery on expectations. Are there obvious reasons why the MVP approach is not taken up or even met with resistance by project or product owners in organisations?
A MVP is often seen as a phase of the product development and release life cycle, when developing new solutions or replacing existing solutions. The expectation level in this situations and certainly in the latter case is not the same, maybe even not similar to those of a green-field development. In the context of the succesion of an existing product or process, one is often confronted with an extensive set of requirements, and a high level of detail in the requests detailing the needs for the product to be developed. Unless the product to be developed holds a complete change of concept, the set of requirements is often that large and detailed that the initial release can, in my opinion, hardly be considered a MVP.
The cited MVP is not really an MVP in a large number of enterprise projects. In the context of the succession planning of an existing application, the product to be delivered, even though the technology or system basis changes is a new release, not a new product. Current users expect the new product to perform better than the product they are currently using. It should contain all current features, be modern and have increased performance and improved usability compared to the current product. The product to be delivered is not subject of discovery and learning it is expected to be an improvement for features well known and – when lucky – well documented.
It is to be discussed whether providing automated support to a running process can result in the release of an MVP. Although the (software) product may be new and its usage and usability is subject to testing and feedback, process and information support requirements are sufficiently known to be explicitly discussed and documented. It might be that the processes to be supported are fraught with bureaucratic controls and needs to be cut down, the concept as such is not to be tested.
Even when we are talking about a real MVP, there are potential reasons for reluctancy to adopt a MVP as step in the way to the implementation of a solution of product are to be found in relationships, the disruptive nature of the approach where majority of interactions are contractually defined.
Relationship with the IT solution supplier – an external contractor is expected to work for a limited time and should deliver the product as defined initially, when granting the project. Even when working with the internal company or organisation’s own IT department, relations are often not as smooth as they could be. In some cases the department is seen as an enemy, it transpires to know better the needs of the business than business departments do and behave in a similar contractual relationship as the external supplier. Challenged by lack of resources, they tend to block of extra requests or changes in scope or requirements, increasing resentment while taking a reactive stance rather than pro-actively participating in the definition of the product along and together with the business department that is product owner.
We want everything to go to plan attitude is part of the overall culture we live in. This need-to-be-in-control, and to act in a predictable way, leads to a lack of open communication, where mistakes, misunderstandings and planning deviation are tucked away by not communicating or vaguely communicating about progress, results and problems while preceding in the development of the product. An efficiency culture that starts with the premise that all is to be done based on past experience, known facts and on precedents or similar activities executed in the past increases expectations and decreases the perceived need to be explicit and clear when expressing requirements and desires. It has been done before, relax, is the standard (requested) attitude… Focus is not on a discovery of the real need and the real added value as design thinking promotes.
In order to profit fully from agile and lean innovation concepts including the use of MVPs, a cultural turn around is needed for departments and enterprises that will thrive on innovation and adaptability. They should go from a command and control view on things, where the few plan and think out products and the majority execute without question what they are ordered to do, to a learning and improvement attitude where everything is in flux, knowledge is gained and all participants in the organisation participate in creating it and its products. All concerned have to work with the same overall purpose in mind, bringing down the walls between departments and teams introduced with an eye on efficiency and task specialisation.

LeSS is the Holocracy for IT

Posted on By Koenraad Seys
In the past I wrote about holocracy and self managing teams as a system of balance, stressing mutual interest propagating overall business goals like in feudal society. All teams are driven by a purpose of providing a certain service to some other entity or to the final customer.  Teams specialise in a functional domain. Coordination between teams is done through a team delegate participating in the team meetings of teams for which they have a client or provider relation.
Large Scale Scrum (LeSS) is a methodology for developing products along the lines of SCRUM adapted for scaling. It depends largely on focused teams directed at customer, product or product feature, functioning with minimal or no management overhead. Member teams work together at realising a complex product for a business represented by what is called a Product Owner in SCRUM. Coordinating happens through participation of a team members in each others team. A team is tasked with developing a component or better a feature that fits in the overall product and therefore they have to understand what is needed by the business team/unit that will be using the software product supporting their processes. As such it applies the same philosophy as Holocracy but adapted for software or ICT departments.
As holocracy teams are oriented at certain products or customer groups there should be a match with the product or feature teams identified in the software development LeSS teams. This match will ensure better understanding, efficiency as well as continuity in the development and direction of development.
When applying the logic fully, it means pairs are formed between business and ICT teams. In some cases the product provided by the ICT group might cover different customer channels, customer target groups or products addressing the clientele or at least parts of it. It might lead to priority discussions. However, relations between both sides of the story are clear. The lines of communication are short and priority discussion can be held in a transparent way with all parties involved present. Pairing will improve focus, direction and understanding of needs of both customer and the people providing the necessary services. Integrated working will avoid the need of translating business needs to IT requirements. The Product Owner as linking pin is part of the business team who understands due to proximity better than ever how development of software solutions work. The IT team will understand the needs of the business team better as they have a structural and long term relationship with the business team(s) they support even when stories are rather vague and lack information about the technical implementation of the request.
The functional focus will require a mix of technical skills and requires knowledge sharing on this level. Therefore, the creation of functional/product clusters should not lead to new silos. Technical oriented communities of practice covering the technology used within the organisation should provide a space for sharing knowledge and experiences concerning development practices and infrastructural issues related to deployment and system management. Alternatively people with specialist technical knowledge can be delegated to participate in development of a feature team to bring them up to speed. In this way one can avoid the reflex existing in current organisations to build technology oriented teams focusing on technical components  that tend to live in their world having a hard job understanding business needs.
Pushing the envelope further, a good understanding between business and ICT teams can and will lead to more innovative products and fundamental digitalisation of business processes and customer interaction. The SCRUM methodology stresses the importance of the Product Owner as the person representing the business needs and thus piloting the development team laying out priorities and explaining the underlying reasons for a requested functionality. The relationship is mainly one directional, resulting in smaller incremental changes than what would be able to achieve when ICT potential would be used at its potential. Often scanning incoming documents is positioned as process digitalisation, actually it hardly changes anything more than facilitating the communication of the document through the process. Using a structured data entry form at the start of the process would permit instant data quality controls with the possibility to change and enhance data on the spot. Other examples can be imagined resulting in better use of digital technology. This potential often is not recognised by non tech savvy people concerned mainly with coping with the incoming work volume.
Establishing a tight relationship between ICT and business teams will most certainly enhance business performance when the purpose is clear and bidirectional communication facilitating the creation of added value. Therefore all talents should be used in an environment of mutual willingness to understand participants having different backgrounds.

The feudal organisation

Posted on By Koenraad Seys
Most of us know feudality from school, being the predominant way of organising a state during the Middle Ages. Although embedded in a traditional society based on a stable order imposed by god, some elements may still be of value in current contexts.
Discarding the basis for legitimising the position of nobility as the leaders in the Middle Ages, feudality is mainly a method for distributing power and a way for the king or emperor to exert control over his realm while having a sustainable community.
Looking at the material context of medieval society, feudality was a logical organisational format. Traveling even over short distance was difficult and took time. Roads were rarely paved so using them was mainly restricted to summertime when it was dry and days were long. As it easily took a day to travel to the next village, it was hardly feasible for the lord to enforce strict control on regions further away. Giving instructions and receiving feedback on them easily took weeks. On matters not involving the overall structure, fiefs were alone in their decision process. Although set in a rigid and strictly hierarchical context, legitimised by god, fiefs were largely independent, autarchic units. They had to decide on their operational besognes.
A fief had to be able to subsist independently of others. It could and should survive on its own, provide in its victuals, producing enough agricultural produce for its own inhabitants, be able to construct housing, furniture and tools to get necessary production going. Specialisation was limited. They were also self policing on the level of internal peace keeping and justice. They also produced enough surplus to support nobility and clergy. Their focus was on their purpose: subsist.
They were only called to help when neighbouring or when fiefs of which they were part of were under attack of an external source. On the other hand they presented enough force to ascertain the equilibrium with neighbouring fiefs.
In the ceremony, where a lord got ordained, tokens of trust were exchanged delegating full control to the lord while promising the lord eternal support and assistance. As such the local lord was also representing his higher master to which he had sworn obedience, while assuring representation of his domain with higher authorities when it came to engagements of a broader nature. Other interlinking was extremely limited, thus evolution was slow.
This is the basic setup of feudal society without distortions incurred by powerplay or unbalancing privileges.
Considering current organisations and societal evolutions a new type of distance could be identified. Increasing specialisation, either technical or functional, makes communication across the board more difficult. Vocabulary and practices often differ between groups and they have different support, infrastructure and tooling needs. Competition requires light, flexible and adjustable setups, quick on their feet to respond to changing contexts under their own responsibility not needing to go long ways through the overall organisation to obtain feedback or authorisation. This would take too long.
The medieval principles of autarchic units existing in balance with neighbouring units are also found in new organisation types heralded in modern management literature.
The Connected company defines it a podular organisation where “you divide labor into “businesses within the business”” fully oriented at its customer. An infrastructural platform sees to it that the necessary information and knowledge can be shared and common support activities are mutualised.
In holacracy work is organised in holons, “a whole that is part of a larger whole”. These holons or circles are organised along the lines of business functions and processes and fundamentally autonomous for their internal organisation of work, however constrained by the need of other circles and anchored in the context of the organisation. “The “Lead Link” is appointed by the super-circle to represent its needs in the sub-circle. A lead link holds the perspective and functions needed to align the sub-circle with the purpose, strategy and needs of its broader context. The other link, called a “Representative Link” (…) is elected by the members of the sub-circle, and represents the sub-circle within its super-circle.”
Different to the past, management or leadership overhead is out of the question. Each unit should be self steering based on a set of basic governing principles, mutual member negotiation and unit democracy.
Although recurring in other contexts mechanisms from the past re-appear, ideas are recycled and depend on similar conditions for their success and sustainability.
Each member of the organisation should be taking up responsibilities for the role (holacracy) or tasks assigned to or taken up by him/her, he should act as an engaged adult
Have a clear view on the organisational purpose and vision
Share the common vision or purpose declared or grown in the organisation
Avoid powerplay, created when units see possibilities to lift the equilibrium instated in the initial organisation
When providing a governance framework keep it crisp and stick to general widely applicable rules. Avoid to let it become an elaborate set of detailed rules and procedures.
In this context it is also tempting to retreat in the own autarchic circle, not sharing any knowledge or learning and to focus on the internals of the working of the circle. The businesses in the business not contributing to the whole will eventually lose efficiency by not sharing experience across the board, merely being a franchise or an independent organisation. The potential for corporate learning is clearly available based on the platform services on global level.
Keep connected to your customer (in a broad definition) and continue to observe how needs and behaviour are evolving while capitalising on your talents, knowledge, competences and experience.