Balance is key for us all to prosper and sustain. We can be out of balance for a moment, but if we are out for too long, we grow chronic conditions in ourselves, our team, our business, our community and our environment. We become sick and may accelerate towards the end of our life here on earth.
To learn, and so instead move forward in a direction of positive health and sustainability, and to continuously bring ourselves to better dynamics of play and performance, we must therefore always consider the gap between the demand on ourselves and our competence (ability and capacity) to meet this demand.
Tied closely to this seeking of balance are the concepts of queue and trust, in that a queue limit flow and take us off balance, and over time causes us to grow mistrust in ourselves, each other and our environment. Unchallenged queues are what drown us in fear and pretend, and accelerate our way into “the Land of Doom”.
So let’s go the other way – kill queues and seek rhythm, together!
Learning is not learning
To begin this journey of growing healthy dynamics, let’s firstly look at knowledge and the productivity of knowledge, as learning flows into knowledge, and it is the use of knowledge which brings us balance.
Peter Drucker was keen on our 21st century to reach productivity increases in knowledge work like the productivity increases in manual work we inherited from the 20th century – i.e. bring it up by a factor 50.
To get there he foresaw the relevance of these matters:
- The accountability of productivity lies within each of us via autonomy and self-management
- Productivity is NOT a matter of quantity, quality is of a much higher importance
- We as human beings need to:
– be cared for as investment, not cost
– be deployed based on choice, not necessity
– always ask ourselves the question “what is the job”? (i.e. the effect needed)
– drive for continuous learning and innovation
These foresights are really profound, and from helping to bring about change in the direction Drucker foresaw, I would like to add that Knowledge is not Knowledge, and Learning is not Learning.
Our understanding on what makes up Knowledge and Learning dependents on:
- What we see as the nature of the activities we pursue (routine or first creation), and
- What type of people dependency we see exists in this nature (in- or inter-dependence).
Consequently, we may understand knowledge as anything from an Object (i.e. stored data and information) to Process (i.e. questions of attention which acquire, aggregate and apply information) and from a Tool (i.e. exists and can be manipulated outside humans) to Meaning (i.e. exists as experience and dreams only inside humans), and them all integrated as a whole by Time and Timing.
What is then this knowledge productivity Drucker dreamt of and how does it come about?
Lots of experiments have taken place over the last decades, and to me what stands is the position of Joseph Kessels. Knowledge is what we humans do with information, all else is at best just information.
That doing is to “signal, identify, gather, absorb and interpret” information, and “use it to grow new ability” and “apply this ability to improve and innovate” processes and services.
Knowledge is essentially a human quality – a competence. It is our integration of information which holds a potential impact when applied. Its productivity arises from contexts which release this potential.
We see the consequences of this spelled out, as we advance our use of Artificial Intelligence. Does AI replace knowledge work? or is it indeed not knowledge work AI does? That is, AI is work with information which provides better opportunity for us humans to release our potential and so increase productivity of our knowledge.
Clearly knowledge understood as objects and tools such as the written word in books or algorithms in software are not accelerating knowledge productivity in themselves. On the other hand they enable us to make better use of our potentials, if we both understand to access them and choose to use them.
This goes as well in the field of knowledge understood as both principles of doing, and as a process of questioning, to guide and help us form holistic options of play and decision making.
As we progress faster and faster towards the position on knowledge stated by Joseph, the more clear it is, that only humans have a potential for action which does not depend on stored information alone, however with humans interacting with it.
Because of these insights, we must measure the result of knowledge productivity in terms of improvements and innovation of processes and services, and use the quantity vs quality foresight of Drucker – knowledge productivity comes about when we ask “what is the job (i.e. effect needed)?”
Sustainable value lies not in the improved or innovative ‘process’ or ‘service’ as such, it lies in what we in the past perhaps considered the side consequence, namely the growing of our capability to generate such improvements and innovations, and so our human ability to create quality – together!
Indeed when we offer ideas to improve or innovate, and take on ourselves an accountability for quality (what is the job – i.e. effect), not only quantity (how do we do it – i.e. output), then the conditions for our growth changes.
We grow totally new competencies, and the speed and smartness of our learning processes directly influence this. For these reasons, knowledge productivity is fundamentally challenging all our previous ideas of leadership, teamwork and impact.
Clearly we cannot learn to collaborate by looking it up on the internet, it takes more than the contexts of AI to learn to collaborate. We must lead ourselves to learn faster and better, together.
How do we move ourselves beyond beliefs in the power of books, training and bosses?
How do we grow learning environments that invite us to faster explore and create quality together?
A starting point is to appreciate that learning is no longer just to prepare us to do work (i.e. replicate), and so enable us to execute pre-defined tasks within boundaries.
Today learning is motivated by at least 4 different purposes, namely to:
- Innovate – Increase impact, and so experiment on ways that are more effective as a whole
- Improve – Change current standard, find better ways to get the desired output
- Process – Prepare for the standard, and train to be able to do it
- Execute – Do the standard job, when it is needed
Learning is now the most fundamental part of work, and so the organizing of the work contexts and learning are inseparable. This is also why certificates and exam papers are becoming less relevant – maybe even useless.
Learning Flow – take 1: Opening up to Possibility
Let’s next dive into lands where smart learning for competence growth is flourishing.
As Mihaly Csikszentmihalyi helped us realise, then we learn best, when we find ourselves move ahead in a steady continuous stream – when we are in a state of flow.
There are two very key aspects to this:
- We are not holding ourselves back or are being hold back
- We move along in a pace that fits our rhythm of play, our tune in life
In other words, we experience in ourselves a rhythm of learning when the challenge of play we pursue is in harmony with our growing of competence. Too much frightens and overworks, and too little bores and underutilize.
We are in flow in a balanced range between the possible and the doable.
At its core, we are doing the work for the pleasure of doing it (so not for external re-(a)wards), we have a clear purpose, ego has fallen away, and we have a feeling of being in charge; it looks a lot like playing and having fun.
To test it out a little bit, try playing this very simple game.
Firstly, find a phone that is smart. Prepare it to track time. Secondly, realize the game consists of 2 rounds, each using below 2 rows of information, and the tracking of time, from start to finish.
- Row #1 : Focus Reduces Chaos
- Row #2 : 1 2 3 4 5 6 7 8 9 19 11 12 13 14 15 16 17
Thirdly, ready, set, go – play each game accordingly:
- Round 1: Shift between rows of information. Write letter, number, letter…
- Round 2: Write firstly the full sentence and then write the numbers from 1 to 17.
What was the consequence for you? Did you feel the difference?
What did the time tracking tell you on the difference in movement over time?
If we use this very simple game to reflect on what happens in many of our environments, we realize that we often experience these “round 1”-out-of-balance-situations, where we without much purpose jump from one task to another, and perhaps that we at times are caught up in a vicious cycle creating stress.
What puts us of balance is when we fully lose the playful nature of work, and take part in a reality with severe imbalances between request and competence – both as individuals and teams. Not being able to honor expectations to self and others is killing us, and so the systemic over promise and under delivery.
Consider this classic situation I have learned from Jan Willem Tromp of Epic Flow.
It depicts a team that together has a certain capacity of work, which it is able to apply within a given period of time; however it is met with a level of service requests that is several times higher.
Further, at a little more detailed level, imagine the team is asked to work on 3 projects at the same time, and that each project requires work to be done by our 4 different colleagues in the team.
Which project does our colleague doing job A need to work on first? How will he know of the consequences his choice implies to end2end outcomes of all projects in the portfolio as a whole, and so the jobs of his colleagues?
As we realize, depending on the choice of when our colleague doing the A jobs, will do the A job for each project, downstream consequences will follow for all other colleagues, and very importantly none are really aware of all this inter-dependency stuff. We need to be very lucky to choose the better sequence.
Yes, due to blindness in seeing our inter-dependency, in fact as soon as we are engaged in 3 or more projects at the same time, the consequences explode into troubles of unrealistic demand planning, changing requirements as time goes by, lack of resources at the right time points, lack of focus and just the feeling of too much bloody work delivering nothing much, besides all the blaming on each other.
What is really happening in these environments set up for failure, and so not enabling us to learn and grow competence?
Yes – to survive – we procrastinate and multi-task, and jump from project to project doing a little bit here and there, as directed by what feels most urgent right now.
We observe ourselves waste time in back2back info-meetings, small steps on the spot and lots of prioritization questions. We are not moving, but cause lots of motion.
If we are so bold as to create visibility to our complete portfolio of projects, we are hit by a chock. Not only are we working on 3 projects at the same time deploying critical shared pools of people, we are working on 100+ projects at the same time.
We are not leading at all, but instead administer and report in blindness. We forget to be human, to enable use and to finish. To cope we even take ourselves out of the loop, and find ourselves continuously spewing out more and more ambitions and ideas to fix things, as if that would help.
The socialization of this hit and run behavior represents another vicious cycle, that causes sickness, loss of credibility in us to deliver on our words, and so mistrust, suspicion and yes, further imbalance. To bring back balance and movement towards knowledge productivity, we must now re-build trust.
Your knowledge is only information to me.
I did not live the experience that you did, and I do not hold the potential for action which you do – and vice versa.
As an example, what kind of reaction does the following text cause in you?
It deosn’t mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer be at the rghit pclae. The rset can be a toatl mses, and you can sitll raed it wouthit porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe.
Yes – it is weird – and at the same time it is revealing a fundamental truth.
In a high trust reality we can be unprecise and still be understood. In a low trust reality even we are being very measured and precise, we are still being misunderstood.
So, did we find ourselves focused on what is wrong in the text, or did we focus on what the text is offering us to build on and with?
Trust is a dynamic spiraling phenomenon – so is mistrust.
When we trust ourselves and each other, we move ahead together and build on each other’s offerings.
We use straight talk, demonstrate respect, create transparency, listen first and take accountability for outcomes, together. We explore the edge of the possible, experiment and grow impactful competence, and are paid with great results.
This grows further our credibility and in turn that makes us even more open, inclusive and focused next time. In short as our impact contribution grows, so does our trust.
“Strategy x Execution x Trust = Results” – Stephen Covey
When we do not feel safe as we are overburdened and underutilized, we are not very eager to explore new opportunities to improve and innovate.
When we have little trust in ourselves and feel threatened, we spend instead most of our energy on defending the past, precision of definitions, motions and win-lose influencing games (politics).
We stand still, try to cover ass and seek protection from losing out.
We cannot fake our way to another reality – it is time for a beginners mind.
All this trust stuff is counter-intuitive to many people; but it is about time we get rid of the old school practices of bossing around with each other, and instead replace them with better ones.
A beginner’s mind is empty. It holds no ideas or rules. It is open, eager, receptive and so like to explore many possibilities. Yes, let’s challenge ourselves to see anew, like a small child. As young children we naturally live our questions, and so are not as adults assumed by our answers. Be open to the possibilities.
“One prerequisite for originality is that a person shall not be inclined to impose his preconceptions on the fact as he sees them. Rather, he must be able to learn something new, even if this means that the ideas and notions that are comfortable or dear to him may be overturned”. – David Bohm
These are keys to bring ourselves to our beginners mind and plays with possibility:
- Intent – play with open cards, declare direction and assume a game of abundance
- Vulnerability – show ourselves as we really are, do not pretend to be someone else
- Mutual attractiveness – show we want each other to succeed together
- Confidence and passion – build on and use our personal strengths
- Inter-dependency – rely mutually and explicitly on each other, no one exists in a vacuum
- Integrity – commit to accountability, stand for something while always be open for change
Learn to See Flow, and then to Challenge Queues, Together
In our journey of building up trust again to achieve balance and healthy dynamics, let’s then take a hard look at our “Land of Queues”, and the possibilities that exist to transform them into a “Land of Flow”.
These classic queues we all know very well.
Picture 8: A Super Market Queue
Picture 9: An Airline Check -In Queue
Picture 10: A Hospital Queue
Picture 11: A Traffic Queue
Less thought of are the queues scattered throughout our stream of value – from vision, prototype, design, development, release, sale, purchase, make, deliver, use and to after service. Is there a queue in front of them all?
Reflecting further, most likely we also experience queues in front of all our enabling services to our value stream – i.e. we queue up for analysis, marketing, management review, finance, it, legal and talent. Yes, queues may exist in front of any functional domain. They are all over the place!
Essentially all queues are waiting lines.
Do we like to wait or do we like to let our customer wait?
Of course not, we know our time on earth is limited, and that queues are influencing highly the judgment of service, and go hand in hand with growing or destroying credibility and trust.
As we are not stupid, we of course really want to avoid queues, and so we normally plan capacity to be able to meet incoming demand, and so lessen the risk that this whole queue thing grows crazy.
To plan capacity we normally need to know how much our service is asked for over a period, and how much we are able to do in the same period, and so we aggregate and manage accordingly. At least we think so.
The not so funny thing is that the queue thing still happens all the time. How come?
Let’s take a closer look at the systemic construct of a service.
There are 4 key elements to it:
- An arrival point of a customer (entry timing – Request)
- A waiting period 2 be served (queue – To Do)
- A service period being served (server – Doing)
- A departure period of a customer (exit timing – Done)
and then there is what we all know of very well – the culture of customers to be served.
We all have experienced different cultures in our lives, like those that are with some:
- Degree of Discipline – First In or Last In, First Served
- Degree of Chaos – Best Connected/Biggest Boss/Loudest Mouth In, First Served
What happens in our everyday life? How do we respond to queues?
- Non-Visible – We get angry (e.g. complain and threaten to move orders elsewhere)
- Some Visibility – We react & avoid them (e.g. big traffic queue, we take another route)
- Full Visibility – We proact & manage them (e.g. invest in self-service options)
An important insight is indeed that our type of culture dramatically changes the performance of our entire business service system, which is key for us to bring life back from all the imbalances.
As an example think about what it means to the level of service performance, that a service has:
- A single queue in front of multiple servers of service, or
- A separate queue in front of each server of service
Which of these two service systems will perform or flow the best?
Yes, the first, as the rhythm of customer arrival will be better, and as well the general flow not so easily stopped from long service times at one particular server of service.
Below are some visuals to make things a little easier to grasp. We see in them a classic road service with 2 lanes. The level of customer success we describe by 6 different levels on the stability of the service dynamic.
Degree of Discipline
A Free Flow
B Stable Flow
C Borderline Stable Flow
Picture 13 A, B, C: Stable Service Dynamics and High Levels of Customer Success
Degree of Chaos
D Borderline Unstable
F Flow Breakdown
Picture 13 D,E, F: Unstable Service Dynamics and Low Levels of Customer Success
What will many side roads connected to a 2 lane main road mean in terms of the arrival of cars to the main road?
Well, they will arrive much more randomly, and so cause a higher density on the road, and therefore there is a much greater risk that the whole traffic dynamic more often becomes unstable and chaotic.
What will it mean, if there is only one lane to use?
Well, if the car in that lane has a breakdown, then traffic comes to a complete standstill.
What happens to our behavior when we are faced with unstable service dynamics, and does it help us as car drivers to get serviced better and faster?
We know it all too well; traffic arriving to the road with very variable timing causes traffic to behave very variably on the road.
Look e.g. to Brussels where I live at the moment. There is a very high level of connectivity (so many roads linked up per kilometer) and on top scarcity of road. Some lanes even have bike tracks painted on top – also called suicide lanes – and others have trams running in the same lane.
In this geographically small city – the capital of Europe – we find some of the worst traffic conditions in the world. Queues without end, as well as quite an aggressive individualistic guerrilla warfare traffic culture.
Even car drivers park their car on one lane roads to do their side road business. It is horrible for the traffic flow, and the trust level is low. All are on their own.
It is generally better to have less connecting points to a service, and more lanes of service.
To all this about the availability of a road and the culture of using it, we need also focus on what enables our road to be there – i.e. the service creation and the maintenance of our service system.
Let’s say the management of the road service in Brussels strongly believes in hirarchy, expertise (vertical knowledge domain drive), and that everybody must answer individually to daddy or mommy.
Further, that the managers therefore do not consider service performance to be about customers of road service, and them achieving a safe, fast and reliable ride, however instead inwardly perceiving it to be about individual operations efficiency – i.e. the number of road jobs produced over a standard period of time.
What will that do to the rhythm and flow of traffic?
We know it – too well – at least in Brussels. Road workers deliver as many jobs as they can from 08.00 to 16.00, and so the users of road – the customers aka drivers of cars, bikes and trams – struggle even more to find available capacity when they most need it, and so experience dramatically longer queues as well as a very broken queue discipline.
This – the availability of service, the culture of using the service, as well as the enabling services of creation and maintenance – all means that even our capacity is enough for the aggregate service needs in a deterministic and theoretical world; it always ends up with periods of poor rhythm in the real world.
We always have variability in the arrival of customers (the timing of entering) to be served, the actual service time (the service cycle time), the service opening time (the up time) and the exiting of customers (the timing of leaving).
This is a fundamental insight, which links us to three derived consequences for any service business:
- Service businesses create service delays – waiting time – even with excess capacity
- Service businesses overload at less than 100 percent capacity usage
- Service times are non-linear with the usage of service (work load)
Loading capacity usage from 0 to 50 percent will not mean much for the service times which our customers will experience. We are in the stable dynamic.
However, when the load of usage moves from 50 percent and upwards, then the service times our customers will experience grow by a much higher factor – in the end exponentially until we totally break down. We are in the unstable service dynamic.
Just a small change in load can lead to huge changes in service lead times. If we add 5% more load at 90% capacity usage, then service durations will at least double. Our projects will take the double time to finish.
This is opposite to traditional intuition of keeping everybody busy with back2back calendaring, and asking people to find capacity by influencing around or better time management methods.
In fact, it is quite normal before making use of these insights, to find that 85%+ of the time a typical project takes to complete consists of just waiting time. It can be lower, if colleagues do tend to add their own time in evenings and weekends to add extra capacity, however still it will be in the high 70ies.
Think a little about what this really implies. Most work today is non-repetitive knowledge work. There are huge variations in arrival times as well as in the duration of the knowledge jobs, and so the more our service offering implies knowledge work, the more our intuition of going for high loads and efficiency of self and team is totally of the mark. We cause lives wasted on waiting.
Further, if we are already very busy, then we make things much worse by shouting or playing sneaky manipulating tricks to get our service job given a high level priority – i.e. trying to jump the queues.
It is striking that as we get more educated, we tend to keep using the beliefs of manual work in organising work, and by doing so we actually slow ourselves and our impact down, and so put a break on our journey to higher levels of knowledge productivity.
Said in another way; in most work, our opportunity lies in not having “knowledge work”-in-process sit idle in queues; it does not lie much in terms of people being idle.
Donald Reinertsen has stated excellent insights on these matters for decades, and based on it we need to realize and accept that the best service flow occurs at a balance range – never at max. speed nor at max. capacity load.
We also must be very careful not to jump to conclusions and so think that the solution is to dramatically decrease the variability in knowledge work by e.g. going six sigma on everything and so deploy an army of black belts, as this will eliminate our ability to actually do knowledge work. We would do no testing experiments and learn nothing new. Achieve no improvement and no innovation. Just follow six sigma procedure.
There’s always variability in complexity and difficulty. Some things take more time to test, longer to design or are harder to build. As work flows through our stream, there are interruptions, tests failing and rework to be done and so designs taking several iterations to get them right.
Learning flow – take 2: natural learning
Queues of knowledge work invisibly drain us of energy. They are basic reasons for stress and scaled down levels of learning. Let’s instead go for healthy dynamics, and look for answers to our range of balance between the possible and the doable. This we do with economics and that on an ongoing basis.
In a service value stream that has no queue, the service time will be the sum of the time it takes to do knowledge work for each knowledge worker engaged in the service.
That means decision gates will not happen in a specific week where management is in. It will be done as needed, and so only take the 10 min spent to discuss and come to a decision. Research on an idea will not take four weeks of ping ponging opinions; it will take the 2 days of prototyping, and so forth.
A project that is run with every knowledge worker being on standby for work to arrive, and so be ready to perform immediately, will mean very short service lead times, however it will also be costly in terms of all that standby time not being deployed for anything else than waiting for knowledge work to arrive.
On the other extreme, then long queues for service is reflecting the totally opposite reality. The longer the queue, the longer also the service lead time, and so the knowledge work will mostly just sit there, and each day it sits in a “to do”-queue is an extra day added to the total service lead time.
Depending on our customer need, this can make or break the whole purpose of a customer asking for the service in the first place. If our customer misses a deadline, they may not win their order.
So, queues of service have very direct economic impact. They increase inventory of knowledge work (design-in-process) and stall valuable projects to be delivered which increases our risk of severe loss, even total loss of business.
Yet in spite of this, cost of delays are rarely understood, tracked or enable decision making in our ways to set up, deliver, use, maintain or stop business services and processes.
Most of our practices are only aware of the cost of excess, and cannot help us on questions like whether it is better we:
- Run at 80% capacity with a 2 week delay or at 90% capacity with a 8 week delay?
- Delay service delivery by 6 weeks to include an extra requirement?
To find our balance range dynamics, we must look beyond the classical cost practices.
- The cost of delay is the amount of profit (not sales) which we lose when we deliver late service. It is typically money over time – so e.g. 250000 euros per month.
We get cost-of-delay numbers by methods of aproximating the value of time 2 market.
We may firstly ask colleagues, what they perceive to be the cost of delay
This most likely will be just as chocking an experience as the exercise on getting a full overview on all projects being worked on at the same time.
We will observe a very big difference in our understandings on the consequences of delay. It is not unnormal to find our perceptions vary with a very high factor – 30-50!
Take a really close look at that cost of delay reality
We all know that in life there are a few constants – such as change – and its cousin – the holy s-curve.
What happens when we are delayed are several things related to change and s-curves, which together makes up our cost of delay.
Generally when we delay, our peak sales will not be as high as it could have been, as competition will take market away from us while we are waiting for our service to be complete, and at the end of the sales curve we will lose our maximum sales. It will simply be pushed out and into oblivion – gone it is.
This happens over and over again. In new ocean markets it is most severe, as the first movers tend to create the market space and simply define the standards, leaving only scraps to others.
That is why we need to grow shared understandings on the value of speed (time2market), and enable us to easily differentiate between costs of delay situations.
The value of speed is not the same to each customer. A truck, a bus, a tractor, a caravan or a car, generally do not have the same cost of delay consequences in our traffic example above, though we may allow them to use the same road capacity at the same time. Maybe we should not do that!
If we managed our traffic system according to cost of delay profiles, it would look very different. As a start we would not allow tractors on the main road systems.
The reason many do not get this, is that they value connectivity higher than flow, and so they allow their service system to be congested by offering a lot of connection points as well as very varied service jobs to go through the same service system. That is a big mistake, if we want to achieve better learning flow and higher levels of impact!
Take the traffic systems and Belgium as the example again. Here the number of connection points per kilometer are several times higher than in other countries, and as well all types of motor vehicles are ok to use them. It feels awful to take part in.
I suppose no-one as a whole are accountable for the traffic outcomes in the Belgium Traffic Service System; therefore a good idea is to make the consequences felt by someone to improve this.
Below are some of the classic “cost of delay”-profiles (classes of service) popularised by David Anderson, which help us with a simple understanding on different cost of delay consequences which exists for customers in our service system. When we can only directionally know of the cost of delays, service classes are much better than nothing.
The class of service perspectives provoke us to differentiate our services and processes to the customer impact reality, and so plan capacity with a roughly right amount of slack, as it enables us to do a simple prioritization on service jobs not based on first in first out principles, but value in first out principles.
Further, they make us realize how services not attended can evolve over time and so jump service classes, in that mid-term uncertainties unattended tend to become short term realities and expedites.
Quantify the delay using one of several methods. Roughly right is most often ok!
To understand cost of delay consequences we can apply several methods going from the simple and rough cut to the rather sophisticated based on economic modelling of each service job or project.
- Quantify Cost of Delay (Dollars per week)
- Qualitative Cost of Delay (3×3 matrix)
- Categorize by Urgency (Classes of Service)
- Ignore Cost of Delay (Return On Investment, Hipo Opinion, Value/Effort)
In more operational service contexts the classes of service thinking and practices are enough, whereas in service contexts where design and development gives us the bread on the table, then a little further detail helps.
A middle ground is to make a simple value vs urgency matrix with rough cut cost of delay consequences on our different service classes.
Where the really big money are at stake we must make use of simple economic project models – business case logics of revenue vs costs over time – clarifying the cost of delay by say each week or month.
With knowledge on the cost of excess (typically salaries) and the cost of delay (profit loss by time delay) from the projects in our portfolio, what we need to appreciate is that optimum balance is not in a single point. It is luckily in a range of very similar economic consequences.
We find this range, at the bottom of the total expected cost curve, and so even in the usage of an economical model, directionally ok numbers are sufficient.
Change the focus of our conversation, as well as our conversation
Knowledge work can easily drown in opinions on priorities which goes with the imbalances between request and competence, and so the queuing and waiting time troubles, and our guerilla ware fare tactics and cultures to get our own stuff pushed through to look individually good (be heroes).
We absolutely need to stop asking in isolation when something will be done or what will be expensed. These questions are skewing our mindsets into seeking busyness at lowest immediate cost, and so out of balance with cost of delays, these are the key questions that cause our imbalances!
It is a really great idea instead to change our focus from a critical path (and the eternal change of Gantt charts) to a critical chain perspective (and our holistic rhythm of movement) in our portfolio of knowledge work, projects and services.
When we understand and are able to communicate cost of delays, then we are able to balance into the cost equation the need for speed, use our bias for loss aversion, and much easier make the right trade-off decisions, and get the real priority orders going – and as a whole not go for all at the same time!
Further, in the execution of the projects or service jobs themselves, if we are spending 10000 of euros a week, it must embarrass us, when we do not know, if a week of delay is worth 10000 or 500000 euros.
To enable the new conversation, we need to both see the queue and act on its dynamic, together
Building a lot on the excellent work of Donald Reinertsen are next a number of examples on what we can do to achieve better balance, as well as how we dynamically can work together to keep this balance, and even better, how we can work together to make the balance happen at even more attractive ranges of play.
This we accomplish by deploying some tactical tricks to the way we begin, sequence and finish our knowledge work, and so enable a much better learning flow environment.
Measure the queue
Output (i.e. the new recipe) or activity (developing a new recipe) shows no queue, and so if we only look at output or activity we will not notice our queues.
By subtracting “work time” from “total time” we get an idea. Left is the waiting or queue time of the specific knowledge work, project, service class or service system.
We need to be really good at managing our team capacity to manage knowledge work well. Stop managing individual timeliness and instead manage our queues as a whole.
See the queue
Overemphasis on activity (busyness) and output (jobs done) by each knowledge worker and/or bosses prevents us as a whole from wanting to look for the queues that we create and overload ourselves with.
To get an understanding of what really goes on, we may use a cumulative flow diagram.
This diagram helps us see the queue size, how it evolved, the number of customer arrivals as well as the length of service of customers who have exited our service system.
A vertical distance represents the number of service jobs in queue at a given time. A horizontal distance represents time a given service job sits in the queue.
It is a great way to spot an emerging queue build up, and so it enables us to intervene early on, as it shows us when our entire service dynamic is in danger of going from service levels of discipline to service levels of chaos. We do not need to wait for knowledge work to happen to realize these consequences.
As an example, think of a supermarket. If we go from 6 to 3 booths, as 3 cashiers go to help in the store, then we will know quickly from the queue size build up, the customer effect of that move in available capacity, and so faster than from later seeing customer total service times more than double.
From the cumulative flow diagram is derived something very important – Little’s Law – which basically means that in general service systems, the average waiting time can be found by dividing the average queue size (the work-in-process or design-in-process) with the average service lead time.
Average waiting time = queue size (wip or dip) / average service lead time – Little’s Law
(Time till I get coffee = number of people in line / people served per minute)
It also means we have two general ways to monitor the health of a knowledge work service. Queue size or service lead time. Further, we get the insight that the queue size is the leading indicator to the completion date of knowledge work. Not the missed deadlines, which is a lagging indicator!
Therefore it matters a great deal that we not only monitor our flow, however also enable our service system to be able to pro-act to queue sizes (WIPs or DIPs) instead of just to re-act to service lead times.
We also learn from the cumulative flow diagram that knowledge work in small batches are really key to avoid queues and queue build up behaviors, and so we can actually reduce our queues without making any change in the capacity of the process by just decreasing our batch sizes.
All we need to do is to bring our allowed queue sizes (WIPs or DIPs) down, then our range of balance moves to a better economic reality, and to a better use of our capacity aka an enabled learning flow. So we really need to enable ourselves to monitor and intervene in the service dynamic to keep a good rhythm.
With this kind of overview, suddenly capacity flex models matter a great deal. When we can see the queues this way and get information early enough, then we have – a lot more – opportunity to keep the right things moving. When we cannot see the queues, delays are unavoidable.
An example is a freeway road service system targeting 90-120 km per hour flows, and so acting on queue size built up, by intervening in the number of allowed connecting points, as well as stabilizing the discipline by dynamically setting speed limits, as well as informing the traffic of upcoming bottlenecks.
Location of bottlenecks, foresee build up risks and safeguard service system dynamics
A further help for better balance is to orient ourselves towards bottlenecks in our flow and to setup approaches to save guard them on the short term as well as challenge ourselves to evolve them to be less of an issue on the longer term – i.e. less risk of leading to unstable service dynamics.
Bottlenecks are typically found where knowledge workers are shared, so where several types of service are asking for the same knowledge worker or team to take part in the service delivery.
What is also a core matter, is that it is not a good option to ask a knowledge worker team in a bottleneck situation to just work faster, as it encourages multi-tasking, and higher levels of risk taking and generally backfires with much higher levels of re-work to put back into our service queue.
Instead in each service stream we ideally need to enable a smooth hand over from knowledge work to knowledge work, and avoid the need to transport or store “design- or service-in-process”.
Therefore it is really helpful to put our knowledge work in sequence (circular or linear sequences are both good) and deploy a way to signal to each other where in our service stream a specific service-in-process (wip or dip) is sitting right now.
Both of these needs can be addressed by co-locating teams – so they are able to communicate, easily able to hand-over and signal to each other as they process the work – as well as by using a visual approach to make fully transparent what goes on.
This approach is called Lean Kanban – popularised by David Anderson – and there is now a whole consultancy industry growing around the use of it – especially in software development environments. It is simply a great approach for this purpose.
Sequence capacity usage via information economics
When we measure and see, and know of our general bottlenecks well, we can begin to sequence our service queues to maximum value and minimum pain.
Which service job should we do first? The 10 week service job with a 25k per week cost of delay or the 25 week job with a 25k cost of delay per week?
To help us decide and dynamically sequence, we need to always use emerging information, information economics and our cost of delay insights, and so sequence the service jobs in our queue based on that, and regularly visualize queue consequence via our Kanban.
The key is not to prioritise what is on your schedule, the key is to schedule your priorities – Stephen Covey
Simply put, if there is a 50% probability of an outcome on something, then there is a high value in knowing of a positive or negative outcome, where as if there is 100% or 0% probability of an outcome, there is no real value in knowing this outcome.
Hence it makes sense to go for the maximum value of information, at the minimum cost of creating it, and it is therefore a good idea to both be concerned with the effectiveness in generating information of value as well as the timing of this information generation.
This means for instance that prototyping and small batch knowledge work or projects early on are key to us, as they cheaper and faster provide us information of value, whereas complex, big scope projects or service jobs taking place over many months – even years – are more tricky to sequence.
Our sequencing is essentially about decisions to delay some service requests over others, as we cannot do all at the same time, nor does it make economic or psychological sense to do so.
Generally 3 key sequencing principles help us to move ahead a portfolio of service requests.
- Shortest Service Job first (i.e. the prototype)
- Highest Delay Cost first (i.e. the high value customer impact project)
- Highest Weighted Delay Cost first (i.e. the high weight prototype or project first)
Picture 30: Shortest first
Picture 31: Highest cost of delay first
Picture 32: Highest delay cost first
Ideally we start with the highest weighted service requests first, though we can differentiate based on the length and cost realities like this:
- Projected lengths and costs of delay are equal, then use first in first out (FIFO)
- All costs of delay are equal, use shortest jobs first (SJF)
- Projected lengths are equal, use highest cost of delay jobs first (HCDF)
- Projected lengths are all different use weighted shortest job first (WSJF)
Said in other words, choose firstly the service requests or projects that minimize risks fastest, and monitor events of significant change in the risks of the portfolio.
Manage Service Demand (one or several lines of service request queuing)
Capacity to request a new service easily exceeds our capacity to finish, as does our capacity to request changes to our capacity to execute these changes while also delivering the service requested in the first place.
Hence we need methods of relief to avoid drowning our complete service system with requests for service and changes to ongoing services (the WIPs or DIPs).
Generally speaking service requests need to be managed from 3 logics:
- Go/No Go on requests – only commit to real demand, weed out failure demand
- Now/Later scheduling – use cost of delay and info economics to schedule
- Stop/Continue doing the service – kill projects where case for business disappears
For all 3 logics we want to limit the amount of work we accept. By doing that we improve the flow, achieve better quality and throughput.
This may mean a longer service request queue or backlog at times, but the benefits of faster and more consistent delivery allow us to work on fewer things at the same time, and so we actually deliver what we committed to deliver.
Put this up against the eternal conversations with customers to explain and assure that “yes, we have started” and “yes, we are moving fine”, and then taking much longer to deliver after these kinds of commitment talks.
Concrete examples of these demand limitation practices are to:
- Limit the number of:
– projects we run at the same time
– projects we run at the same time per class of service in our system
- Take out some requirements to finalize on time (i.e. avoid cost of delay consequences)
- Completely stop a project as emerging information makes a broken case for business
So all in all, once we see the effect of queues, we explicitly therefore manage the demand by limiting the size of queue sizes (work in process or development in process) to keep the work flowing smoothly.
This may mean, at times, that a particular knowledge worker sits idle for a period of time, rather than piling more knowledge work into the queue. Through the lens of the complete service system, idle time of people is much better than loading the service system with more requests that just slows down everything for everyone.
Reduce batch sizes
Large batches cause schedule growth and exponential costs, and they tend to cause even larger batches, as they are limited by their worst parts. Small batches on the contrary help deliver much better as they:
- Accelerate feedback and so provide better information economics outcomes
- Allow us to finetune capacity usage instead of being blocked for weeks on end.
- Reduce risk, vulnerability, lead time and overheads
- Increase motivation and focus, knowledge growth and knowledge productivity
- Enable us to act sooner and so be more flexible
Hence the popularity of scrum and agile, and why we must be very careful with big batch tendencies especially in how projects are funded, phased, architectured, detail planned, reviewed, signed off etc.
We must bring carefulness into how we manage the sources of large batch tendencies by challenging heavy scoping, funding, organizing, ways of working, detailed requirement, analysis, reviews and market research.
Another tactic to help bring us to more healthy service dynamics is to consider the variability in the service system and besides focus on reducing variability in arrival time, also focus on being able to differentiate between healthy variability (that is helping us grow knowledge) and stubborn variability (that stops us from deploying knowledge).
Healthy variability is typically found in design and development experimenting work, stubborn variability is typically found in execution work without defined standards.
Firstly, let’s measure the variability to understand the nature of it. Look for the variability in:
- Demand (arrival rate & amount)
- Work Duration (time length)
- Queue Size (WIP/DIP) (over time / periods)
Secondly, let’s use this knowledge to challenge ourselves to deploy practices that bring especially demand request and queue size patterns into more regularity.
Thirdly, let us clearly differentiate between knowledge creation work duration patterns (which are needed for test-to-design flows) and knowledge usage work duration patterns (which are needed for design-to-deliver flows).
To this add that it is a great help to design and deploy a standard process framework for the services being delivered in our service system including a project model, if our service includes e.g. delivering projects.
Lastly, a help to reduce stubborn variation is to e.g. reuse design solutions, and so only focus design work on critical-to-impact matters – the real knowledge growth work. This dramatically decrease the work duration variability, while still innovating the right solutions to the target customers.
Employing more specialists is expensive and we are often reluctant to invest a specialist’s time to train others. Instead we tend to manage specialist knowledge workers for efficiency because of this. Further we rarely reward on the breath of skills, however breath we need to deal with queues.
When more colleagues are enabled to do different knowledge work, then even we are not all operating at the same level of efficiency, we are still able to shrink our queues faster, and so another tactic to attack growing queues is not only to rely on one colleague to get the knowledge work done. Teams of multi-skilled people are by far the better choice.
To have general specialists – or in talent language T-shaped knowledge workers – is a really great way to add temporary capacity when needed. Designers who can test or Engineers who are happy to pair up. They may this way together safeguard our service dynamics around bottleneck knowledge work.
Growing Environments of Learning Flow
The science of natural change and growth shows that at critical points in the development of anything the rules of the game shift.
A tree, for example, as it matures, slows down its quantitative growth (height & length) and changes to qualitative growth (branches & leaves). The tree changes its modus operandi and becomes more integrated into a complex ecosystem. It grows deep relationships with the soil and provides shade and habitat to other plants and animals.
Nature knows change best, she’s been in this business the longest – George Land
The tree in this way goes from independency with own purpose – growing large and powerful – to inter-dependency with shared purpose – developing deeper relationships of impact with its environment.
This realization is profound for learning flow and knowledge productivity.
With this let’s end this piece by going back to the beginning, and that balance is key for us all to prosper and sustain. We get there by working on our service dynamics, and deploying quite some opposite practices to what we have learned in school or by our boss.
The primary enabler is to collaborate as teams, and together see and visualize the queues in our service system. Based on this visualization we can together challenge our flow, and so reduce all the economic and psychological limitations of queues to us all, and so bring our environment to a disciplined rhythm without lots of waiting time and individual pressure.
Though, we cannot underestimate the transformation challenge it implies for us to move to these inter-dependency ways of working, as we are up against deep rooted dogmas of especially our old past world ways of independence planning and execution.
The trouble of the independent world is, that it assumes wrongly that queues are free, it focus on overheads, and assumes these overheads are driven by the number of batches. It considers slack to be bad and so aim to always keep self and others busy, and finally it assumes experts and specialists are more productive than generalists working as a collaborating team.
In classic manual operations, where queues are inventory on the work floor, and so sits on the balance sheet as cash stored in unrealized assets, we spend a lot of effort on getting them realized faster or lessened.
Inventory in knowledge work is information – ideas, designs and algorithms – and most of that is invisible. We tend to only see it in the form of long lead times, delayed feedback, constantly shifting priorities and the eternal status reporting circus. It does not appear as an asset, however as an expense.
Because of that, we easily ignore it, and so if we increase the number of service requests, there is no warning bell. We may look more stressed, but there is no way of knowing what the changed level in service requests really has done to our knowledge work environment and so our learning flow.
Imagine then, that we double the number of people to work in our service system. We will realize immediately as we are troubled by not having enough space, and as we will discuss on end from which budget the extra money to the extra salaries are to be found.
The impact of knowledge work inventory is however just as severe for the flow of knowledge work as inventory is for manual operations, and so the longer unfinished knowledge work just sits there and watch the world pass by, the greater the danger that the value of this great information will disappear.
There is nothing easier to get into, than a vicious cycle of knowledge productivity decrease, by overpromising and overcommitting. It always makes us enter the “Land of Queues”, and soon thereafter we end up in mistrusts and the “Lands of Mixing Up and Despair”.
This is why bringing people together is a necessity for growing better balance and to increase knowledge productivity, and we must be careful not to let Super Chickens or Sloppy Sams loose, and so be able to socially control away any of these characters, and instead invite and include learning impact driven people.
As I jokingly say to my friends, in the Elite believing systems of France too many 10 year olds cannot read, write or do math, and in the Equality believing systems of my homeland Denmark too many 10 year olds cannot read, write or do math. Both approaches waste human potential, as they do not balance well the possible with the doable, and so cause less movement and so learning flow. Less real collaboration and impact driven team work.
The middle way learns us to work together. To collaborate, not be coordinating Elites or cooperating Equals. That is to bring the knowledge of all of us to use in creating even better solutions. Improvements and Innovations.
It demands we take accountability to seek flow – together – and as today is the first day of our future, let’s make it happen. We owe it to ourselves, future generations and our planet.