Mr. Richie Etwaru, Director of Applied Innovation & Transformation Portfolio at UBS, makes a poignant statement on the nature of work in this post Human as a Service that introduces a way of looking at how people and work duties are matched to each other in a way that improves the overall resilience of the business model and encourages creativity in the talent pool:
“Practitioners looking to the future for a vision of the IT department a decade or two ahead must stop looking at the cloud as a noun and start looking at clouding as a verb. Cloud is a noun describing a set of efficiency principles that can now be applied to a newly stateless once state-ful storage and compute IT estate driven by virtualization and cloud operating systems. It could be debated that the condominium or hotel were early commercial clouds, a housing cloud that was multi-tenet. Similarly Zipcar can be argued as a car cloud particularly if someone can zip a car into the Zipcar fleet and reap the corollary commercial benefits when said car is rented …
Looking one or two decades ahead, leaders are pressed to answer what can be clouded above and beyond compute and storage… Leaders must imagine a world where Workplace can be a Service, Expertise can be a Service, Business Process can be a Service…”
Mr. Etwaru is referring to how the cloud is transforming the workplace from fixed assets and resources of computing power to one where such resources come on-demand and can be utilized from anywhere. He takes it further by considering talent as a cloud, and descries an interesting view of the contrasting notions of ‘stateful’ and ‘stateless’ design of work. This introduces an interesting principle for designing an agile, flexible business model especially for balancing scale of business while improving talent and resource management.
What are the implications of a stateful versus a stateless model?
In technology, a stateful activity or session sets an agreement for all the resources along the path of process flow to be solely assigned for the duration of the activity. Each node in the flow is aware of the state or context of the session and has agreed or committed to the cause, so to speak, and thus we call it a stateful system. It requires contracting resources in advance and making sure all the pieces are in place before the activity can begin. The resources are essentially occupied and cannot do anything else until the session ends.
A stateless system on the other hand does not require that reservation of resources, and instead each step of the process completes it portion of activity and there is some indication of whom should receive the output next. They are generally not aware of any other nodes in the system other than from whom they received it and to whom they will send it, and do not need to keep track of the overall condition. Setting up such a process flow is easier since you do not need to align everything beforehand, and each node does not need to maintain state.
There are pros and cons to both, although it generally boils down to the overhead involved in knowing previous and next steps. Stateful devices made more efficient use of resources but were fairly inflexible or ‘brittle’. Stateless devices were cheaper and simpler to create, requiring less memory and processing to keep track of things. In the end, a stateless system is much more agile and resilient.
In the 1990s there was quite the cold war going on in the world of networks between the very idea of stateful and stateless networks. It was a classic battle between telecom carriers and the upstarts of the Internet service provider industry.
The traditional telecommunications companies of the time had very extensive stateful, session-oriented, switched networks, and proposed using a new protocol called ATM that continues this model. [This refers to Asynchronous Transfer Mode, not Automated Teller Machines.] In comparison, the Internet service providers relied on the packet-oriented stateless nature of the Internet Protocol. The Internet was designed so that long-haul communications could be disrupted anywhere along the web of network lines and still continue. A stateful network meant that any disruption would cut the communication.
While using the Internet may seem like a continuous session when you go onto Web sites and navigate through many pages or interact on a social network, it really is not; it is noticeable when accessing YouTube over a slow network and the video pauses partway as the network ‘slows down’. In practice, it turns out that stateless models can effectively emulate stateful behavior, for the vast majority of purposes.
The Internet Router triumphed over the ATM switch as the primary model of how the world communicates to this day. This says something: even though a stateless network cannot absolutely make guarantees on delivery or completion of its task or even the path it may take, this downside is overcome by the sheer scalability and flexibility of this model over stateful systems.
How does this apply to Work as a stateless model?
Coming back to Mr. Etwaru’s point, think about your business processes and how people are assigned long-term to specific jobs. These are essentially stateful reservation of people to tasks for a long period of time typically to a single manager and set of duties. Their expertise is available but far too often reserved for one area of business. Even if they wanted to they would often not be able to help too much other areas regardless of how much their expertise was needed.
Why is this? We often consider only the primary talents of an individual, their main skills or knowledge domain. The goal is to maximize their potential by applying them where they are best suited. Noble intent, but it ignores the reality that people are generally multidimensional and everyone has creativity and knowledge that can apply to other areas. A stateful talent system focuses on a single purpose and seeks to optimize it to the utmost; a stateless model recognizes that they could be doing different things at different times and balances variety with skill.
Too often, it is a matter of bureaucracy. The cost of their employment is managed at a departmental or team level and the manager needs to make sure they are contributing to that effort. Their work assignments or business commitments they plan to deliver for that time period, say a year, stay fixed to the duties of that team.
In comparison, Crowdsourcing and Collective Intelligence looks at work in a stateless manner, by breaking down a large project or set of work into smaller units that each requires completion by an available worker with the right expertise. The worker is engaged for a relatively shorter duration required to complete, can often self-select the work they want to complete, and depending on their own self-management skills can take on multiple jobs in parallel.
I don’t even use the word employee, because as we have seen from many Open Innovation and collective intelligence models, they may even come from outside the organization. For that matter, it might even be a team doing the work and not a single person; the pay for the job is the same amount, and the team decides how to distribute it.
There are two ideas here: the statelessness and the free market approach to work assignments. An enterprise business process can generally continue in the same overall approach, but it is the assignment of duties and reservation of resources that is dynamic.
This is how we can really apply the expertise and capacity of, as Mr. Etwaru describes it, Humans as a Service, in a dynamic, agile manner that can scale much more easily overcoming the stateful overhead mindset engendered by bureaucracy. That dynamism and free-form structure allows mobility across an enterprise, inspires creativity by allowing people to work on different things following their changing interests, and drives the spirit of free markets.
