Efficient Expediency?

Steve, Tobbe and I were discussing actions and the differences between working in efficient ways and working in expedient ways.

Efficient is a non-judgemental word and rather clinical – are we working in ways that reduce or eliminate the waste of resources, effort, time and money?

Expediency has a moral element – doing things in ways that are convenient regardless of whether they are morally the right things to do.

I did not notice my attitude to visual management changing – it struck me only recently. When I first started to work with cards on the wall, I thought it was about accountability. I would feel awful if I pointed to a card that I said I would finish yesterday and I still had not completed it today. Now I feel fine using cards on the wall to see how the work is flowing. It gives me ways to capture data and articulate where the workflow is being impacted. The focus is not on me and my accountability (there are plenty of other ways to look after that in the workplace) – the focus is on how we can make the system of work flow better.

Getting back to the words – expedient and efficient. Kanban-style visual management is a very efficient way to visualise the work in order to improve it, it allows us to see queues of work that are otherwise invisible. I have also heard horror stories of it being used to victimise people – it is an expedient tool in that respect. Someone could stand at the board, point at a card and interrogate the team about who is working on it, why it has not moved and yelling could happen. Unfortunately expediency also often includes efficiency.

Because I had not noticed the change in my attitude, I am careful to explain the difference when speaking to others who are new to visual management – it is likely that they may be feeling the accountability side just as I did at first.

 

OBSERVATIONS IN HOW THINGS GO 2

As a society based in the post Industrial revolution, where productivity and maximising profit rule the landscape and dictate our daily lives. We strive for “Efficiency” in our work lives and even our daily lives and many of us never really think about what we’re doing and the costs of our search for better, faster, more!

Efficiency vs Expediency.

Years ago I was developing a database, the demands placed upon the database were simplistic and basic. In essence it was a list, used to check the availability and validity of numbers. The idea was to wash a random bucket of numbers to see if they fit the criteria set by the customer. These numbers could have easily simply occupied a simplistic table format and been fine. The customer would have been happy and content yet, I found the basic minimal number of columns, data points inappropriate for the customers future needs.

Yes, I opted for Efficiency over Expediency. The reason was I have a scientific background and we never throw anything out, especially data. The data is only as good as your mindfulness and awareness while collecting it. Many a scientific study has suffered and been less important because basic and minor data was not collected during the experiment. In science I would never disregard any data which may be needed later. Anticipating future data needs and possible uses, is key to Efficiency.

So I was predisposed to put myself in the customers shoes and try and anticipate possible future data requirements. The upshot of this was that for very little extra effort, an extra few columns and a few extra lines of code; the customer could benefit from future data mining and analysis.

The effort required to develop the database was the same !

So why do we choose Expediency over actual Efficiency ?

The daily activity of trying to finish our work items steers us towards Rapid Solutions which seem Efficient; yet this very Expediency often costs many times more with rework, rebuilds and even the complete redevelopment when parameters shift as future needs become apparent.

The old saying “A stitch in time, saves nine” springs to mind. The mindfulness and mending of a small tear prevents the need for major reworking and effort.

So next time, ask yourself is this done for Expediency or actual Efficiency, and hopefully we can get a head of the curve and put our future efforts into better things than Rework.

The way I see this is that most of us try to do the best we can but a few remind me of the Ferreters of old who would let go any pregnant female rabbits so they would get work next year, to reduce the rabbit population.

Expediency has become our efficiency.

Action and Activity

Action – doing something that will result in a valuable outcome

Activity – doing something – regardless of the result

We tend to think that if we are not doing something then we are not being productive – we need to be cautious of doing things because we think that more is better. There are many examples where more is not better – even drinking water. We need to stay hydrated and we think that drinking more water is better for us – but over a certain amount, it can cause toxic and dangerous effects on our bodies.

Since the discussion with Tobbe and Steve recently, I’ve been reflecting about times in my life when I’ve mistaken activity for action – there’s more than I’d care to admit at this point.

We should check what we are doing and ask ourselves – is it activity for the sake of activity or are we taking action and making progress – whatever the endeavour? To answer this we need to understand purpose.

One of my favourite things to check is the purpose of reports that are being generated. I’ve seen situations where there are 100’s and 1000’s of reports – and no one really knows how they are being used. The activity version of a report, likely came from an initial need to make a decision – let us imagine that we needed 3 types of data to make that decision – so we ask for a report every week with those 3 types of data. And then – due to the ephemeral role of data in decision making – we quickly discover that we need another 2 elements of data. Very quickly, we can have a report being generated every week with lots of data elements. A lovely amount of activity – but what if we are not making those decisions any more? And there are better ways to gather data when we need to make a decision – reports can be very . inefficient.

Whatever we are doing, ask about the purpose of it. Is it activity for the sake of doing something? (And therefore can we stop doing it?). Or is it action? (And we should continue).

Activity vs Action.

In our modern world we are constantly expected to rush and frantically finish our tasks in the name of efficiency. Yet often we find that activity does not translate into the desired action or outcome. It is this “Rush to Action” which is the actual issue, often leading to poor outcomes and undesirable states of mind.

So why do we do it?

The basic fact is that we generally can not distinguish between activity and action. The realm of busywork is populated with people filled with a sense of accomplishment. The simple fact is we are driven by the evolutionary reflex of Fight or Flight. This predisposes us to rapidly respond by reaction, it is this proclivity to activity which makes us feel a sense of control when we are in activity. The difference between activity and action, is often only observed in the final outcome therefore it is very difficult for us and any onlooker to distinguish the two.

Doing things make us feel empowered and better; we feel in control and have a sense of fulfilment because we are doing something about it. Yet this activity is a hollow victory, if the end goals are not reached. The true reward is when we attain our objectives and goals.

If we take the real world example of Cave Diving, a highly technical and inherently dangerous activity, which happens to be fun and scary. Imagine you are diving in a sinkhole cave system and before you know it, you realise you’ve reached the bottom and have lost your bearings and the rest of your group. Initial instinct would be to begin searching for the others and this naturally becomes more frantic as time passes. Although this is a natural and understandable reaction, it usually is not the best course of action. This initial behaviour which manifests itself as activity, will often cause greater problems. The reason frantic activity in such a situation is not a good idea is that you will stir up any silt and mud off the bottom, this will muddy the water and reduce your visibility to the extent you can loose your orientation to the stage where you don’t even know which way is up.

Activity is not always the best action.

So in the above example reactionary activity is highly problematic but even in this example calmer heads and cool action will prevail. Surrounded by zero visibility, not knowing which way is up many would feel lost yet the fact that the bubbles you expire using SCUBA gear will always rise actually will help you identify which way is up. This simple fact and calm action can and will safe your life.

This predisposition to activity can and often does muddy the water when we are trying to determine the actions necessary to attain our goals. Running around like a headless chicken, is an apt description because we loose our senses in the frantic rush. We don’t see, don’t hear and can not clearly understand which are the best options, opportunities and course of actions.

Observations In How Things Go

Have you ever noticed the way new ideas and innovations seem to decay with their mainstream acceptance and growth?

The usual scenario plays out something like this….

1) A new idea or innovation is developed. The core community which includes the originators of the concept and a small group of early adopters contribute to its betterment, fine tuning and working the concept. These early adopters also promote the particular idea, innovation or methodology.

2) The community is comprised of mostly like-minded people all contributing their particular talents for the betterment of the whole. This is the pinnacle of the communal symbiosis for any new idea or innovation. The community is focused only on the betterment of the concept.

3) Now things begin to get noticed by the larger population and the core community starts to grow. This seems a good thing but in reality, the growth of the group leads to the decay and ultimate corruption of the original value of the idea of innovation.

So why is there; this inevitable degeneration and how does it happen?

What seems to happen is that as more people become aware of the concept, the fewer true collaborative contributors you get entering the community. The new idea quickly becomes the latest trend and is USED in the truest sense of word. The new community becomes widely known and becomes seen as a must do/have item. It is during this transitioning that the foundation principles of the original community are under the greatest threat.

The core community becomes the latest bandwagon to jump onto by the rest of the broader community. It is this extra weight of the “Hangers On” jumping on the Bandwagon that breaks the axel and makes the wheels fall off. These “Hangers On”, USE the new idea or innovation as a means to virtue signal and big note themselves. The focus drastically shifts from collaboration and the concepts improvement, to a “What’s in it for me” narrative.

This often leads to the decay and ultimate failure of most new ideas.

These “Hangers On” join the new community not out of like mindedness or a collaborative philosophy with a willingness to contribute and embrace the foundational idea or philosophy of collaboration. Their motivation is to be seen as part of, what I call, “the leading herd”.

So how do you identify the “Hangers On”?

They rarely understand the innovation or the collaborative nature of learning, they just want a quick fix to their problems. Just like students wanting to know the answers rather than putting the effort into actually learning and understanding the lessons they are taught.

Some final thought to share.

“With great acceptance comes greater corruption.”

If you are a member of a core group be watchful of the decay which will degrade the foundations of your community. This doesn’t mean not to share your ideas or innovations but to understand that you can only really learn when you have reached the particular mind set or mental maturity to actually learn and understand.

Knowing something does not mean you understand it.

Knowledge is not Wisdom but only its starting place.

Anything learnt needs to become part of your daily experience.

Not everyone is ready to learn and embrace new and foreign ideas at any particular time.

The Factory Analogy for Software

This is a reflection piece working on similar themes to a post by Tobbe ‘The Software Factory — an idea wrong enough to be useful’

When we think about automation, it is easy to imagine factories. The standardisation of work that was brought in with ideas such as The Principles of Scientific Management by Frederick Winslow Taylor allowed us to automate jobs that were previously performed by craftspeople. So it is pretty easy to think of software development as like a factory because we are automating functions – but the ‘goods’ we are producing are transactions – not physical items.

I like Tobbe’s idea of the flexible factory line where we have teams and architecture that support delivering software in more flexible ways. Most of us do not think about factories like that. I had a part-time job packing biscuits in a health food factory working my way through university. So when I think about factories, I am thinking about highly repetitive (and boring) tasks that are getting automated.

Where we trip ourselves up is using factories as an analogy and mis-applying the metrics that are useful for high-volume repetitive tasks to tasks that are less repetitive. Even though I was manually assembling the boxes for the biscuits, I would pride myself on finding more efficient ways to do this – and shaving a few seconds off this part of the process (which I did at the start of each shift) was useful as well as rewarding. This is where tools such as control charts, six sigma and paying attention to changes in trends is very useful. The production version of a piece of software is similar to a factory in this way – I really want to know if my many transactions per minute start to take even a tiny bit longer to execute – this could indicate a problem that is easy to fix and avoid a big outage. I once looked after a system that lost sync between the 2 databases and it took 24 hours to re-sync (with degraded performance for the end users over that entire day). We made sure that when we found out what had caused the issue, we watched the early warning signs with a lot more rigour and I’m happy to say that it did not happen again.

Installing new code is like changing the setup of a factory. In my health food factory example, it might be automating the biscuit packing job that I did. I imagine that if we automated the whole process, then the factory might be offline for a few days – losing a few days of production and therefore sales. Taking an agile approach, perhaps we just automate parts of the process in one go, such as starting with the box assembly. I’m not sure how big a machine to assemble cardboard boxes would be, or how much it would cost – but we could get in the experts who have done it before and they could tell us. We might use project metrics such as on time, scope and budget to ensure that we are not causing too much disruption to the factory production and sales. We can also go back to the production metrics to see if we are making a difference to cycle or lead times, once we have installed the new parts. There might be a way to install some of the packing automation without disrupting production and we would need to design the factory in a different way to the one that I was working with if we needed to have continuous production while upgrading the machinery. This example is like the release management process when we deploy new software into the production environment – we should be using metrics that allow this process to become more efficient and project-based metrics would be appropriate – especially if we add the quality check about the impact the change has to the production environment.

Software development is like deciding what we need to automate and then designing the machines to perform that automation. If no-one had built a box assembler before, then we would need to observe the manual process, the steps surrounding it and then design the machine. We would need to take into account how it would be maintained – this is a bit like the architecture role in software design – in the factory, we would not be making large machines out of gold – it is too soft, very expensive and would be hard to maintain – but it would be nice and shiny. In software design – how do we make sure that it integrates well into the existing software and requires minimal operational intervention? We do not want to be having to re-index the database every day – just like we would not want to have to service machines every day.

What if we decide to produce a different type of item. In the health food factory we also had lines that produced pies and cakes – which were separate to the machinery that produced biscuits. What if the company decided to manufacture something different, it could be a small difference such as a new type of biscuit or a large difference might be to manufacture coffee mugs. Whether there are sales out there for a new biscuit or coffee mugs is very similar to identifying if there are needs for new software features and we can use the same human centred design or user experience toolsets for physical and virtual things. Once we’ve identified the need we then need to decide if we should start a separate production line or modify an existing one. It is hard to imagine being able to manufacture pottery mugs and biscuits on the same factory line (and health regulations would likely not allow it) – but I have seen people try and add new functions to a piece of software that was never designed to do that new function. An example is where we were asked to add a fraud-handling function to an application which would have incurred a huge cost (in time and money) when we already had a separate system that could do what was required with much less cost.

How we measure the effectiveness of new items in a factory or features in software is very different to how we measure the efficiency of the production environment for both. We look at how sales are progressing, the level of interest shown by Customers etc. At this point the analogy is breaking and becoming less useful – the key point of this post is that using a factory as an analogy for software development can be useful in the ways described. We need to remember that an analogy is only saying that elements of software development and operation are like a factory – and we need to be careful that we do not equate building software with assembling items on a factory production line – especially if we then try to apply factory production metrics to software development.

Splitting, Refraction and Facets

 

Chatting with Steve and Tobbe – we were discussing refraction – light going into a prism and then splitting into a lovely rainbow. It is useful to slightly separate things and it can help us to clarify terminology.

A good example is the term Product Management – I was asked for a definition – so my first place of reference was ‘Escaping the Build Trap’ by Melissa Perri – with an excellent description of the role of a good product manager. This helped a lot – and when I looked into the situation a bit more, I realised that there was more to it. In conversations, not only did we start mixing together the terms Product Manager and Product Owner, but there was something else that was more than the role.

The landing point was to split it out into a few different facets; Profession, Role, Skills and Process – there could be other facets – these were the helpful ones for the recent conversations.

The Profession of Product Management grew from marketing and brand management and has evolved as organisations place more focus on Customer experience and the technology supporting that experience. In some places your career could take you through a range of product management roles all the way up to CPO – Chief Product Officer.

The Role of a Product Manager is to be able to articulate the ‘why’ of a product or feature so that the various teams can build the ‘what’. There is a lot more to it than this – but this is also where it is useful to split out the role from the skills and process facets.

The skills of Product Management need to be performed by many roles. There is the skill of stakeholder engagement to understand needs, goals and drivers. Being good at this skill means that the skill of prioritisation gets a bit easier. Then there are other skills such as data-driven decision making – all of us could use some of these skills in our work activities and we certainly should develop enough of these to be able to understand the outcomes we are aiming for (not just getting the bit of work done).

Product Management in Processes was a bit of a surprise when I noticed it. If we think about large organisations that allocate a certain percentage of time to innovation, this is an example of it. The organisation has prioritised innovation – allocated effort (which is time and therefore budget) with the outcome being to identify and develop new opportunities. The decision about the amount of time to dedicate and the level of priority is a product management decision that has been adopted as part of the regular planning and scheduling process. I’m certain that there are other aspects of product management that we could embed into processes and I will be looking for them.

I have previously blogged about the gradients of misinterpretation – those are still there, in this example there are gradients between one ‘end’ of the definition of Product Management and the other ‘end’. The point of this post is that is can be useful to put a definition through a ‘prism’ and split out some of its aspects or facets into discreet chunks.

“Need to Know Framework” derived from the PRISM

Trying to work out what you need to know and which information is most relevant at a particular time is like trying to hit a moving target. Not impossible but many factors play a role in the result. We all know that things change, yet we can fortify ourselves by becoming aware of which factors can impact us either directly or indirectly. Even factors out of our control can be planned for and risks mitigated.

The idea of a “Need to Know Framework” is actually an acknowledgement of how things used to be. The traditionally small groups of people working and existing together, organically gave rise to a sharing of information and knowledge, each person knew what the other person was doing and a network of awareness of the whole developed naturally. In the modern workplace the scale actually prevents the easy flow of information between indirectly but still connected groups. The recent ideas of tribes, regularly scheduled meeting and intranets etc. all are modern devices to try and replace the paradox of increasing isolation in larger groups.

So the only way forward is to begin at the level of the individual and instil a sense of “the Whole”. It is only when we appreciate the perspectives and requirements of others in the group that the greater good of “the Whole” moves forward. Some of the greatest advances in human history have only occurred when a discipline is examined from another perspective.

The need to understand the interconnections and dependancies that impact our tasks, is crucial to the understanding of the environment or “ecosystem” that our body of work will exist in over time.

It is essential for us to examine and determine which information and facts we will require. The resulting maturity that will develop, if we attain this perspective will be essential in helping us to reach our goals. The byproduct of striving to this end will be an increase in “Transparency” and a Need to Know Framework where each piece of information, can easily be prioritised into impact and according to our specific needs.

So how do can we get to this point?

Well it is only when we realise that just focusing on the immediate and specific task at hand, although seemingly efficient is actually detrimental to the ultimate whole. When any one thing is focused upon solely the result is always that the whole suffers. This does not mean that concentration on a particular task is bad but that any task no matter how small must and should be considered as part of a larger system. It doesn’t matter if your API is perfection, well coded, efficient and a masterpiece if it can not interact with its larger ecosystem.

So how do you generate a Need to Know Framework” ?

The inspiration for this comes from newtonian physics, in particular Refraction of light through a Prism.

Using the PRISM we can utilise the colours as indicators of the Importance, Directness and Impact of Information.

Centrally at Level 1 (RED) would be the direct and immediate information required for you to do the task, and the task only with little or no appreciation of where your task fits into the larger landscape. This is the equivalent of just in time management.

Next at Level 2 (ORANGE) is the knowledge required to perform your task and deliver it.

Level 3 (YELLOW) is information which helps you locate and position the task at hand, within a slightly broader framework. Such as knowing how it will impact and interact with its immediate neighbours or dependences.

Level 4 (GREEN) is information which is not usually considered required but when obtained frames and allows the project or task to comfortably sit within the broader landscape. This type of information aids in allowing you to grasp the interconnection between your task or project and those not directly involved, the first cousins to your work.

Level 5 (BLUE)  this level of information frames you task or project in the broader environment, with awareness of interconnection and nuance between the up stream and down stream relationships.

Level 6 (INDIGO) this level like the colour is between BLUE and VIOLET, the interconnection and interdependencies of all the tasks and projects, yours included and the information required to distill the over arching “5 Year Plan” or Vision..

Level 7 (VIOLET) this is the highest level of separation from your work, and as such is not often seen as essential or even required. Yet, it is the guidance under which all your tasks and projects have been organised to function within. This is the “5 Year Plan” or Vision developed from the Level 6 (INDIGO) information when evaluated and seen in the light of the company in the Global Economic and Social Ecosystems.

TRANSPARENCY; the Emperors New Clothes and You can’t handle the Truth

The very term Transparency as used in the modern world of Management and IT is at best ridiculous and at worst dangerous and an unsettling endeavour.

Harsh words but think about it; few of us could actually deal with knowing every detail about everyone or everything. The human animal has not evolved to store and process billions of bits of data and analyse them without bias or errors. The terms “Option Paralysis” or “Information Overload” spring to mind.

Despite our modern life styles, which are information saturated, we actually only skim or glance over the actual information by taking other people’s narratives as easily digestible chunks. The fact that, very few of us even try to understand the complexities of our own environment natural or man made, socially and biologically is testament to millions of years of evolution which has resulted in our ability to filter and categorise.

This same ability to group similarities and make inferences from them is the very same reason we find the simple task of analysing data, without bias very difficult.

We often extrapolate from only a few data points and behave as if the presented data is “True” because it supports our previously held beliefs. We even find the weight of truth behind an unsubstantiated and sample of one (statistically irrelevant) as highly engaging and important :-Anecdotes.

So is it any wonder why, as a general rule we find true Transparency difficult. We actually don’t want transparency; like the Emperor, once he realised he was naked, we feel exposed; naked for all to mock and find fault. So is it really Transparency that we crave or is it actually the ability to access the information that we need or may need to complete our tasks well and in a timely manner, without any foreseeable obstacles or errors.

So instead of Transparency we actually require a “Need to Know Framework” that would allow us to recognise and highlight important information in concentric layers of Impact and Importance from you the Epicentre. This framework would be derived from the PRISM – a topic for another blog.

How much Transparency?

The picture is an analogy about transparency – I want to see the person step out from behind the pillar – but I really do not want to see into them (their skeleton – or even worse, through their clothing). I’m also quite confident that other people do not want to expose such an extreme level of transparency.

So what is the ‘right’ level of transparency and why to we seek it?

I’m sitting in my lounge room and I can see out the window – it is a frictionless way for me to observe the front yard (through the transparent glass). If there was no window, I would need to go out the front door and walk around the corner to see the front yard – it requires effort and I would need to justify doing it.

At the risk of abusing the window analogy, perhaps what we mean by being transparent about things in the workplace is that we reduce the effort to find out and we also eliminate the need to justify why we want to know. It can be very useful and pleasant to observe things – we can feel happy seeing that the environment is as it should be – and we can take action when things are not ‘right’. If my cat starts to growl looking out the window – there is probably another cat in the front yard and I can choose to chase it away or not. If neither of us could see it (due to the lack of a transparent window in the wall), we would never have known the other cat was there and we would have lost the choice to act.

We need to be careful about where we seek transparency – I do not want my whole house to be made out of glass – and we have curtains over windows when we want privacy.

In the workplace, it would be great if we could see everything without any effort and justification – but it can feel very threatening. When we feel threatened, we want to protect ourselves – so reducing effort in one way (frictionless observation – transparency) can increase effort in another way (trying to close the curtains or cover up our skeletons).

Be careful what level of transparency we ask for – it can be a good thing, and just like other good things (such as water and oxygen), too much of it can cause damage.