What is management? | Scoins.net | DJS

What is management?

A very large topic. Not aiming to explain it here in ways that align with other descriptions but to show instead how it can be gently manipulated.

In general, management is an overhead property of any task or set of tasks. I want to write this work and so I put aside resources such as time so that it can occur. The management of this process includes what it is that is not being done while writing occurs—and in your case while reading occurs—and all of that is reduced to a simple individual level. Management is also the direction of the task, such as deciding that this chapter of explanation should exist.

Matters escalate rapidly when more people are involved and when there is more than a single task in process. [Or, indeed, more than a single process in task]. At this elevated complexity there are competing demands on resource and, often, competing demands for result and/or completion. As people and tasks are added to the situation, so complexity escalates. [Models? Square rule, cube rule? Does management style affect this?] Whether this complexity runs into conflict is one of the (many) matters with which management is concerned. 

This then underlines that management per se is not directly bearing upon the task, though it can have significant effect upon the efficiency of the processes included. Thus it is an overhead, an additional cost. 


Does management lend itself to measurement? 

Can it show that it is effective? Surely some management systems can be shown to produce results faster (better in some way) than others. Surely some systems use fewer resources, some have less maintenance.

Does management subtract from the task / process? Subtract here to mean that it adds load upon the sub-processes of any task so that they are slowed to no other gain. Example, that measurement systems which maintain standards may be so inefficient and measure non-useful criteria that quality is not improved and neither is the process speed. So whatever efficiency is, it needs inspection. Whatever management is, it too needs managing.

Why is there an assumption that management should be paid more than those they are managing? How true is this in practice?

So approaches to management—specifically, people who only do management—include:

• They are generally parasitic upon the work of the producers. Define parasite, separate from symbiote. Managers do not generate product, they are not front-line workers. 

Example: consider a hospital, with a hierarchy of doctors and nurses all dedicated to caring for individuals with ill-health. The managers of hospitals are often not medical experts in the same way that the front-line staff are; they exist to make the expensive experts cost-effective. This does not necessarily mean that a hospital manager should be paid on the same scale as the specialist medics; they are required for different skill sets. It should be true that no administrator takes decision with medical consequences, but arebound to be occasions where the perception of medical need and the perception of administrative need come into conflict. An example would be the actions that occur as the number of available beds reaches low values. You could add to that a perceptible need for accommodation upgrades, so that there were competing demands for space, the need for beds to be removed from availability.

Example: consider a taxi-service. It has a number of drivers on call and in service at any moment who may be in some sense self-employed. In order to collect customers they have a dispatcher who collects incoming requests and allocates these to available drivers. The dispatcher is in effect the manager of the drivers. 

There is a tendency for there to be an assumption that the manager must be paid more than the persons they manage and I question whether this is true and whether it should be true. What applies to taxi-drivers also applies to emergency service units; I am pretty sure that a police dispatcher is paid on a different and lower scale than the policeman being directed, and I think this is right; they are entirely different skill sets.

• Managers could usefully view themselves as facilitators. The standard view of a manager is 'in charge', when 'responsible for' is a more accurate descriptor. I very much prefer 'responsible for the most effective use of' as the descriptor. This suggests that a well-written job description has value.

There is a whole class of educator that views themselves as facilitators and I have come across such people on many staff training days. To an observer it often then appears that the facilitator is short of subject knowledge, because in encouraging their listeners to think and speak for themselves, they use carefully not-loaded questions that rather imply a lack of knowledge, and this behaviour in turn implies that this person could 'facilitate' a course on almost any topic, because the delegates are doing all of the work. There is also a meme within student education that encourages the facilitator role  [enlarge, research; further, discover what is good about this and where it is provably useful].

Problems with management include:

• An assumption that managers must be paid more than those they manage. I think that these are different skill sets and should be rewarded on different scales.

• Parkinson's Law – one of several (expand in a footnote) but I'm thinking of the one that says people rise in a hierarchy to their level of incompetence, one or more levels above their practical level of competence. A common reward for being good at a role is to be promoted to the next level above, which does not necessarily mean the same skills are required any more than it means that the promoted person is ready or equipped for the changed role. Where this occurs, the fault lies quite definitely with the managers (well it would) making those decisions. Worse, such decisions clearly often occur without preparation (training) nor with assistance (post-promotion help) nor with assessment of success (is the promoted person coping, and what can we do about that). Which includes inspection of the senior management's decision process, of course.

• Managers need to reflect upon their own processes. That includes us as individuals working on a singular and personal task and reflecting upon that. It is surprisingly easy to fall into the trap of thinking that because the process was completed, the management must have been adequate. It may have been; there may be a load of previous evidence to show that this is a process well understood and near its optimum. In turn, that might mean that the reflection on the completed task is momentary – but it should still occur, because external circumstances change and we are often unaware of how such external changes can affect a process we had previously thought immune from change.

One issue within this introspection is that quite often there is no such process instilled in the business. Worse, I've worked in places where there is no value given to such introspection and thus the time is viewed as having lost value and therfore negative value. it is seen as a useless process and consequentially should not occur. To make this have any value it must be seen to be useful and valuable. That surely belongs with the ethos of the business, a general willingness to improve, to learn to do better and to value that ability to learn. hence the concept of a 'learning business'. Refer to other chapter, on 'learning business'. 

Many managers themselves have managers, in the same way that processes are part of larger processes. Understandably a higher-level manager has different concerns from those 'below'. But then we should wonder whether part of a manager's role is to look after the whole of the processes for which they are responsible. I say this is self-evident but also that it is clear that this responsibility has been devolved, handed down, but in ways which then absolve the higher manager of responsibility  I say this is a mistake and one that creates problems for all concerned.

Issue to explore here of devolved responsibility. If I move a task from me to you (and we'll call that 'management' for the nonce), where does the responsibility for this task lie? Who owns the result? Is any ownership of result changed by the value of the result? For example, suppose the task reveals a larger issue that might be classed as a problem; who now owns the problem? What happens when the task I've passed on doesn't reach completion or fails to reach an acceptable standard and who owns that result?  Many of these situations move the blame downwards: I do not think that any devolved tasks move the responsibility with them, though they may well share that. Ultimately the task is still 'owned' by the higher-up and so it is a management issue how that is achieved. Herein lies a nest of vipers when the competence for the task does not lie with the manager. 

When a task has been devolved what happens when there is a level of technical skill that the end-worker has that the manager has not? At what point can the worker deny the task, or point to the likelihood of failure? It is one thing if the manager has been very good at the devolved task and so can be expected to 'understand' it. It is quite another if the supervisory role is filled with someone whose competencies do not include an ability to do the particular task. Examples of these two extremes?

Take an example on a construction site; a hole is to be dug for a drain; there is a manager, a digger driver and a banksman. For the purposes of the example let's assume that the digger driver is a relative expert and that the foreman/manager has not operated a digger. The banksman is there to assist with precise placement of the shovel but has never been a driver and, on a site where things are going wrong, will often be sent to do something else. So, if the digger driver is sent off to do some digging work in the vicinity of cables and pipes that should be recognised as being there in the ground, is there fault to be apportioned when the digger driver breaches a pipe or rips a cable? There really shouldn't be a drain so close to other services that there could (will) be a problem without this being known in advance as an issue; where this is known, digging by hand might be a better technique. The argument that says the digger is quicker is blown to pieces as soon as any other services are breached, in this case any other pipework, including another drain. I think it is obvious that the consequences of a service line breach is that the whole job is going to take longer, so that the element of hurry-up worked to produce the opposite effect. So what happens when the digger driver says this is not going to work and before any pipes or cables are damaged? When the management demands that he go get on with it, have they taken the responsibility for it going wrong or is it shared? Is the upper level of site management that has  been pushing for faster results at fault when the 'faster' command results in less safe working? These are issues that ought to be clear at the point when such decisions are made, ("My responsibility" said up front) not to be among those matters generally named in the subsequent blame game. What would be altogether better is a recognition of the balance between expedience and safety – and significant clarity as to who it is that is carrying the responsibility when things go wrong.

Turn this into a story scene.

Connected issues with this general problem are those of trust and teamwork. Generally, blame is an unproductive process and learning from mistakes is, in the long run, going to have much better effects. The person who is fired for making a mistake that their manager should have been able to prevent has learned, among several other things, that this employer is not one that they want to work for. The employer who fires an employee for this mistake has probably learned nothing at all that will prevent a repetition.

Perhaps issues around transparency to point to, maybe enough to point to essay 297. Middle line here is short paragraph and pointer for more.

back to MfU Central

15 minute city   Email: David@Scoins.net      © David Scoins 2021