Managers, change and strategy

In response to one of my posts on management Sergey Timanin ‏tweeted:

“the work [of managers includes] steering the organisation in times of change might be the most invisible to tech people and most under appreciated”

I agree completely with Sergey, many of the changes in and around organizations are invisible to those doing the work. Indeed much, if not most, management work is invisible to those outside the management circle. Does that make it worthless?

Programmers often just want to get on with programming, nothing wrong with that. But sometimes there are changes swirling around, left unmanaged these changes have the potential to sow uncertainty, diminish trust and disrupt work.

In my nature of management post I noted that part of the management role is to interfaced the fuzzy, unknown, unpredicted (unpredictable) world to the very predictable world of machines. This is where Sergey’s observation fits in: the world out that is in a constant state of flux, allow too much of that flux into the work environment and well… you won’t get too much work done!

Managers are sometimes described as “Firewalls”. That is, they shield workers from interruptions and uncertainties that will disrupt their work. This can certainly be true.

But, for every programmer who values their manager as a firewall there is another who believes the manager is unnecessarily filtering - perhaps even controlling or hiding - the information which reaches them and that managers should get out the way and let the information flow direct. These people see managers not as Firewalls but as Gatekeepers who (unnecessarily) restrict the flow of information.

Its easy to see how these two points of view can be simultaneously held by two individual programmers about the same manager in the same company at the same time. One man’s protecting is another man’s hiding, the distinction between Firewall and Gatekeeper is subjective. This is where managers require skills and intuition, both to know what information to hide and what to share and how to communicate with different people with different expectations.

Sergey’s tweet also hints at something another responsibility which is often laid at managers door: that of bringing about change. Particularly being about change in the work environment.

Certainly I would see this as part of a managers role but actually, I would see this as part of everyones role. A good manager should encourage the change ideas of others and help them bring about changes they want to see.

While on occasion a manager may need to discourage - or even prohibit a proposed change - managers should have a role to play in bring about change for the better. However change is usually best when it is bottom-up rather than top-down. I would see a managers role more as fanning the flames of positive change and building momentum more than rolling-out a series of changes decided on in closed rooms.

Traditionally management’s role has been seen as one creating change below in order to satisfy the requests from above: top-down change with the manager as the instrument of delivery. Certainly that is sometimes true. Those who subscribe to view that strategy is planning, that strategy is decided at the top by big brains and passed down the organization would subscribe to that view.

But I don’t.

I believe some strategy is certainly decided at the top and “deployed” or “rolled out” down the organization but, actually, much strategy is bottom-up, it is emergent, it is the result of what happens on the ground, learning at the coal-face, and how this information is interpreted higher up.

Strategy is both emergent and in many cases retrospective. That is to say, strategy is a story we tell afterwards to make sense of what happened and to align future actions. In this case manager’s role is as much about telling stories and passing strategy up the hierarchy as down.

Advice for managing software development?

When I started writing my management blog series one reader expressed their hope that I would give advice on how to manage software development. I’m sorry, but this series has contained very little advice on how to manage software development.

There is a good reason for that: It is hard to give specific advice to managers.

You can’t say “If X happens then do Y”, you can’t even say “If you find yourself in situation A and then B happens then do C.” You can say such things in code, and you can say such things about coding. You can say such things about testing, you can often say such things about product management. But you can’t give such rules to managers, and if you did they would cause more harm than good.

There is a branch of philosophy and logic called contingency theory which talks of such situations. When a set of pre-conditions are satisfied then a certain action is “the right” thing to do.

The problem with managing is that it is difficult to give hard and fast rules, management is not contingent. What managers do, and what decisions they make - and don’t make - is very very dependent on context.

If you were to try and codify all the management actions and decisions you would need an incredible amount of detail and an incredible number of rules. Now computers are getting more powerful and the application of artificial intelligence may render some management decisions subject to contingency theory but for most humans such an approach to decision making is not possible.

And to complicate matters, even if you did have a decision making system much of the information managers have is incomplete or fuzzy, indeed, part of their job, their reason for existing, if to manage in when information is uncertain and the world is changing. (These same factors mean attempts at contingent management, like PRINCE2, are fundamentally misconceived.)

Hence intuition and understanding of context are important. Let me repeat a quote I used a couple of weeks back from Professor Henry Mintzberg:

“Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to manage; it depends on the situation.” Mintzberg, Simply Managing

Management is contextual not contingent, there are few, if any, hard rules.

Consequently I think the best advice I can give to managers, and soon to be managers, is:

• Understand your management philosophy. Understand what you believe, understand how you believe the world works. Your philosophy will inform your decision making.
• It is not enough to just understand ones own philosophy, one needs to continually reflect and build on ones own experiences.

Hence I have very little advice for managers. Well, actually… I do… my “failed” book, Xanpan 2, set out to try and decode many of the problems managers face in software development and build a practical guide to software managers. I was, perhaps, too ambitions. Xanpan 2 is available, as it stands it forms a wonderful appendix to Xanpan.

Management for the masses?

This is an important post. This is the ninth blog post in my mini-series on management, it is the blog post all the others have been building up to, let me recap some key points:

• When creating software there there is coding work, testing work, requirements work and some unavoidable management work
• Removing managers may remove some work (because managers make work for other managers) but there is still a residual amount of management work to do
• Management itself is a skill and requires intuition
• It takes an engineer to manage engineering; people without experience of doing software development are going to struggle
• Management decisions can make a big difference
• All who are called “Manager” are not managers, some are specialists
• There are many non-commissioned managers (NCO managers), those who manage without the title of “Manager”, frequently these people manage with minimal or little management

• Management work may be done by specific people, commissioned or non-commissioned managers, it may also be shared among team members

I’ve deliberately avoided discussion of self-organising or self-managing teams because these subjects deserve posts to themselves. The key point for me is:

• When decisions need to be taken they are best taken close to the point where they are needed
• When decisions are needed those who are staring directly at the decision are often the ones with the most knowledge about what is needed
• Taking decisions at the point the decision is needed also makes for a rapid decision
• It may make sense to get a second opinion, to talk through a decision with another person or in a team, and if the decision effects several people it probably makes sense to consult with them

One way to address these points is to use a self-managing/self-organising team and there are reasons why you might want to do that. But, that is not the only organization structure for satisfying these needs. The underlying principle is:

Devolve authority, pushing authority downwards, decentralise decision making

Whether you devolve to a team as a whole - as in the self-organizing/self-managing model - or to individuals, perhaps to NCOs the aim is to move the decision closer to the work.

Note: I’m avoiding the work empowerment, see my Stop empowering people - End disempowerment! post form last year.

Either way you do it, if you push authority down something else happens:

More people engage in management work

Yes, suddenly coders, testers and analysts who do not think of themselves as managers now need to make management decisions. Even if this is done in the setting of a self-managing/self-organising team management decisions are still being made. Indeed, if the whole team makes the decision they whole team is engaging in a little bit of management.

Everyone in the team starts to take on management attributes.

More importantly, More people need management skills, the whole team need some management skills and the intuition that makes a good manager a good manager.

Think about this for a moment.

Do team members want to go to meetings about management issues?

Do you C++ programmers want to engage in management?

If your Java programmers are now engaging in management where do they learn their management skills?

If your Testers are making on management decisions how do they develop their intuition?

If you accept that management work is a skill set in its own right, and you believe that more people should be involved in managing then you have to ask: how are these people going to learn management skills?

Then there is another side to this…

Talk to any manager about what they actually do, not what they would think they should do, or what they like to be doing but what they actually spend their days doing. You will hear them say things like:

• “I’m constantly fire fighting”
• “I’ve got tons of e-mail to answer”, “My phone is ringing all the time”
• “I never get to do strategy”, “I never get time to think or plan”

One of the characteristics of management work is that it is inherently interrupt driven. (If you don’t believe me go read Henry Mintzberg’s Simply Managing book I mentioned last time.)

So, by involving programmers, testers, analysts, etc. in management we are also opening these people up to interruptions. People will interrupt… well, potentially any team member!

Now if you are a programmer, tester, analysts or what-not please ask yourself: do I want to be interrupted? Am I willing to take the downside of management?

I’ve known plenty of programmers who would definitely answer “No!”

(There is a twist here, Mintzberg also suggests that managers choose to be interrupted. Which could imply that teams could choose not to inflict interruptions on team members but that is not entirely in the team’s gift. What Mintzberg doesn’t say how many of the interruptions would be avoidable? Do managers choose to be managers because they are interrupt driven in nature? - but we digress).

Lean folk will spot that there is a question of variance analysis here: management work has a greater variance than programming or testing and therefore needs to operate on a different cadence. The queues are different. From a lean point of view it makes sense to separate these two types of work because they have different variance and cadence.

Now here is a question.

If management requires skills and intuition (both of which need to be built in a person), and if doing management results in an interrupt driven work pattern then is management better:

a) Centralised in a few people who can be trained in the skills, who develop their intuition and who are tasked to handle interruptions, thereby leaving the majority of the team to focus on technical skills and un-interupted work (hopefully achieving flow)

b) Dispersed with everyone having some management skills (at the cost of technical skills) and some interruptions (at the cost of flow)

c) Other, please specify

For me the answer is (a) but…

If management is centralised it then becomes a question of how centralised? Over centralisation results in the model we see all too often with decisions delayed and taken by people with too little knowledge. The result is depressing and demotivating for those at the code-face.

But if management is organised as a hierarchy of managers then they make work for one another and some decisions end up traversing the hierarchy. So answer (a) is not perfect - this might be another example of dis-economies of scale.

Which brings me back to Non-commissioned managers: I would like to see more people with more management skills embedded closer to the work and working co-operatively within a team. An impure self-organising model if you like.

Any which way, there is no perfect answer. It is about balancing forces.

Managing requires skills and intuition

If you’ve been reading my series of blogs on management it should be clear by now that I think some element of management is essential in software development. You might also have picked up that management, in various forms, is bigger than is commonly realised.

I also believe that good management can make a big difference to software development teams, I agree with Fred Brooks when he wrote:

“Some readers have found it curious that The Mythical Man Month devotes most of the essays to the managerial aspects of software engineering, rather than the many technical issues. This bias ... sprang from [my] conviction that the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.” Brooks, Mythical Man Month, 1995.

Tools, technologies and processes change all the time in software development but some things last. Mythical Man Month is one such, a book originally published in 1975 about work that mainly happened in the 1960s remains, perhaps because management of software development is important.

So why is it manager-less teams do so well? Let me suggest that the value that can be destroyed by bad management is far greater than the value that can be added by good management. I would venture that sometimes no manager is better than a bad management; self-organization doesn’t so much do away with management as do away with managers.

I would also venture that the quality of management in software engineering, indeed IT in general, is pretty poor. This is especially true in the corporate IT world. The standard in software producing firms (ISVs, SIs, etc.) is generally better.

Thus is seems sensible to ask: what makes a good manager? or perhaps, what makes an individual good at managing?

Well, two things.

First, management is a skill set in its own right. Managing requires skills in the same way writing Java, Testing software or Analysing requirements does. Simply appointing someone as a manager does not automatically endowed them with the necessary skills. These skills include communication, analysis, empathy, decision making and others. It helps too to have at good understanding of the business you are working in.

And as I said in my first blog in this series, it takes an engineer to manage engineering. Someone who is an engineer, understands engineering sensibilities, the thought process of engineering and engineers and knows the issues raised in software engineering will make a much better software manager than someone who does not.

Let me quote Fred Brooks again:

“In many ways, managing a large computer programming project is like managing any other large undertaking - in more ways than most programmers believe. But in many other ways it is different - in more ways than most professional managers expect.” Brooks, Mythical Man Month, 1975.

As an industry we fail to recognise that managing is itself a skill-set, and while software managers may learn more from non-software manager there it more to it than “general” management.

But managing software engineering, indeed any form of management, requires something more than skills…

Managing requires Intuition.

That might come as a surprise to some of you but it follows directly from something I blogged about a few weeks back: Management operates in the messy, fuzzy, ambiguous “real world”. Intuition allows one to work in such an environment.

Intuition also allows for rapid decision making; an engineer, especially one schooled in agile and lean startup may often prefer to set up an experiment and test options but such an approach inevitably slows things down. Sure there is a place for hypothesising and testing but sometimes speed is more important. Plus, it is not practical to set up experiments for all the the hundreds of decisions a manager must make during a day. Sometimes having a decision is more important than having the right decision.

Intuition is more difficult to teach, it needs to be built largely from ones own experiences. Some intuition comes from having done the work which is itself being managed. Intuition is also built from past management experiences. And intuition can be enhanced in various way: self-reflection and writing to name two.

This is not to say all management is about intuition, some benefits from analysis - and that requires the skills. There is a mixture here. Let me again quote from Professor Henry Mintzberg:

“Management certainly applies science: managers have to use all the knowledge they can get. But effective managing is more dependent on art and is especially rooted in craft. Art produces ‘insights’ and ‘vision’ based on intuition … and craft is about learning from experience - working things out as the manager goes along.

…

Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to manage; it depends on the situation.” Mintzberg, Simply Managing

That is how I see management: art, craft, science, intuition, and context dependent.

Isn’t that a lot like engineering?

Lets try that quote again with a little change:

“Programming certainly applies science: programmers have to use all the knowledge they can get. But effective programming is more dependent on art and is especially rooted in craft. Art produces ‘insights’ and ‘vision’ based on intuition … and craft is about learning from experience - working things out as the programmer goes along.

…

Put together a good deal of craft with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context. There is no ‘one best way’ to program; it depends on the situation.”

Do you see? - Programming has more in common with management than is commonly recognised.