Control Freak

Years ago I appointed a manager who was a complete disaster, but I didn’t get a clue of this during the appointment process. The problem only appeared when he started work and it turned out that he did not have a clue how to communicate or even get on with the people who worked for him. In contrast to this he was very good at dealing with his peers and me as his manager, which made it very difficult for me to understand just what his team were complaining about.

I’ve seen this again a few times since then and now I can characterise the symptoms. There are some people who think that the team they are part of only includes those who are their equal in the hierarchy and their manager. They simply don’t see themselves as part of a team with the people who work for them.

This affects all of their relationships with their team. Specifically:

• They don’t share their ideas, concerns, hopes etc
• They don’t really listen to their staff. In particular they don’t really appreciate the ideas that their staff have
• They don’t acknowledge that their staff have a role to play in the difficult work the manager is responsible for, such as contributing to strategy or politics.
• They only occasionally talk to their staff in terms of the wider picture (if at all). Normally they deal with individuals about individual details.

This is so demoralising for the team involved, since, more than anything, this is disrespectful. It also fragments the team, stops them seeing the bigger picture and thereby reduces their effectiveness. It even ends up significantly undermining the manager concerned since they are refusing all the support they could otherwise get from a loyal team.

Quite often someone gets appointed to be a manager for the first time because they are such a diligent worker.  They have their own routine and way of getting things done and all of a sudden they have the resources of other people to help them.  The natural temptation for these new managers is to use these people as though they were extensions of themselves.

That means expecting the team to do the things they want done and work the way they work.  If the team is sufficiently compliant then this is generally a successful strategy.  Quite often the team are not that compliant but after a great deal of brow beating they appear to be.  Occasionally some people make a stand to retain their individuality and it all turns nasty.

If that isn’t bad enough then it gets much worse as the manager rises up the chain of command and the person they are responsible for in turn become more senior.  The more senior the team, the more they expect to think for themselves and the more they can resist the push to homogenisation.  The result of this is a painful process to go through as they learn how to manage their team in a different way.

Unfortunately that is the path I followed and it took me some time to learn this the hard way.  My advice would be for new managers, or experienced managers who are now experiencing the pain to learn a different way now.

This better way is to recognise the team as a collection of individuals, each of whom works in a different way and each of whom needs to be treated as an individual.  Getting the best from people is no longer a matter of dominance, but one of discussion, negotiation, understanding and all the other best practices I talk about here.

The strength of a team that works as a team of individuals is far more than the team that works under a single authoritarian control.  It is hard work at first to curb the urge to be a control freak, but the rewards easily outweigh it.

All too often I see results of a survey displayed where someone says ‘so 66% of people are in favour of this change so we should get on and do it’ and I find myself resisting the urge to jump up and say ‘that’s nonsense, don’t you know about statistical significance?’. This happens so often with information that is used for important management decisions that it scares me. Here’s an explanation of just what I’m on about.

The basics

The best way to find out what a group of people think is to ask everyone and get an answer from everyone. However when only some people answer there is a mathematical way of working out just how reliable any answer is, that is Statistical Significance. This method works out from the sample taken, how many people would say the same thing if you asked everyone and just how likely that answer is to be correct. It cannot give you an exact answer, but it can give you a range within which the actual answer lies and you have to determine whether that range is too big to be of any use.

It can also tell you how many replies you need to get in order to get a significant result. It cannot tell you how many to ask since not everyone will reply and that is down to psychology.

The theory

Statisticians over the centuries have noticed that the answers to surveys (amongst other things) fit into patterns of distribution and that with enough answers you can work out what that distribution pattern would be. The more answers you get the more certain you can be about the distribution pattern.

You can never be 100% certain what everyone thinks but with enough answers you can get close. So most statisticians work on the basis of trying to be 95% certain about an answer. However there are times when you might want to be 90% certain or even 99% certain. This degree of certainty about the answer is called the Confidence Level. For most management statistics a 95% Confidence Level is fine. If you are dealing with things like infection rates you might want to use 99%.

The significance of any answer depends on three things:

• Population. The total number of people that you could ask if you asked everyone.
• Sample. The number of people from whom you actually got a response.
• Percentage. The percentage who gave a particular answer to a particular question.

What you get back is a spread of percentages, which is the measure of statistical significance, known as the Confidence Interval. So for example if you did a survey and 75% answered yes then the calculation might tell you that if you asked everyone the actual number who said yes would be between 35% and 115%. However with a larger sample size it might tell you that if you asked everyone the number who said yes would be between 70% and 80%. As you can see the first result is meaningless but the second is very useful.

There are some interesting points to note about the way this spread changes:

• The larger the sample size the smaller the spread. But it is not linear so calculate it, don’t try to guess it.
• For a larger population then a smaller sample relative to the population is needed to get the same degree of spread.
• The closer the percentage of people who give one answer gets to 50% (above or below) then the wider the spread becomes.
• The spread is the same whether you take a positive or negative answer. So for example if 75% said yes and 25% said no then you would get the same answer which ever way you did the calculation.

Examples

There are actually two ways you can use this calculation. One is after you have the answer and the other is before you send a survey. Both of these assume a Confidence Level of 95%.

Example 1 – “ How significant is this answer?

Assume we have a population of 3000 people and we send a survey to which a sample of 300 reply and out of those replies 225 (percentage 75%) say yes to a particular question.

When we do the calculation we find out that if we were to ask everyone the same question then the percentage who would say yes would be between 71.35% and 79.65%. So we can be certain that the majority agree.

The actual calculation returns a Confidence Interval of 4.65% so the lower limit is given by 75% – 4.65% = 71.35% and the upper limit is given by 75% + 4.65% = 79.65%.

If however we only got replies from 30 and of those 22 (73%) said yes then when we do the calculation we find out that if we asked everyone the same question then the number who said yes would be between 58% and 89%. Still a majority but a much wider spread of possible results.

Example 2 – “ How many do I need to ask?

Assume we have a population of 3,000,000 then we can do the reverse calculation to find out what sample size we need to get answers from to get a spread of just 1% on any answer they give. In this case it is 9573.

As the spread changes depending on the percentage who answer, this calculation assumes the worst case, which is that 50% give one particular answer. If we did get 9573 replies and more or less than 50% gave the same answer then the spread would be shorter.

The calculation

The actual calculation is too complicated to explain (and I’ve forgotten it) but you can visit the web site

http://www.surveysystem.com/sscalc.htm

which will do the calculation for you both ways. You can also save this page and do the calculation offline if you want as the code that performs the calculation is all stored with the page.

If there is one skill that is a critical requirement for being a senior manager then it is the ability to read people and and understand what they want, what they don’t want and what they feel about the things that are going on around them.  This is very similar to empathy, but in a conscious way.

So much of what we say is unsaid, if you see what I mean.  There are lots of reasons for this: some people (more than I can ever quite believe) are very cautious about what they say; sometimes the stakes are high and people don’t want to give things away; and some people are just not very good at saying what they want.

Now I’m not saying that the ability to read people is needed to gain a competitive edge, as though it were some form of mind reading.  Though that is definitely a skill that all good salespeople have.  What I mean is that many of us are only looking at the world with one eye open, if that, so having both eyes open allows you to spot the other people that have both eyes open – and they generally turn out to be the most senior people in the room.

Don’t make the mistake of equating good awareness with good communication skills.  Many people can be great at empathy but rubbish communicators.  The two are not related.

Reading people does not come naturally to many, it has to be learnt as a skill.  I only know one way of learning this skill:

When I’m in a meeting I try to take a step back and examine the other people.  I try to read their expressions and their body language; work out if they are comfortable with what is being said or uncomfortable; try to work out what they want; are they straining to say something; are they bored; and so on.  This means getting inside their heads and learning to think like them, understanding what drives them and therefore what their motives are in specific circumstances.  Over time this becomes second nature.

Just remember I’m not talking about any kind of intuitive feelings.  This is detached observation.  When I forget this and try to rely on intuition alone (if there is such a thing) then I generally mess up.

There seems to be an increasing trend for people building systems to ensure they meet current needs but then take that even further with customising them to fit just so. Or sometimes it is expressed as a refusal to consider future needs unless those are clearly expressed and the need for them is well established. Maybe this is an old trend from mainframe days that is going through a resurgence.

Here are some examples of what I mean:

• In software just writing code that does what is needed now without the hooks for what might come later.
• In hardware just configuring the capacity that is needed now without planning for future growth. (As an aside, the thing I find most irritating here is cutting cables to exactly the right length).

To me, almost everything I design must have an virtually obsessive degree of future-proofing built into it. Over the years I’ve built up a whole set of techniques to minimise the impact of this need, so that I get the future proofing I want, but without hassle.

Maybe some people just don’t know how to do that and so they avoid building in the future proofing as they can only see it adding complexity and cost?

I’m fairly convinced that my approach has two significant benefits:

• The first and most obvious is that it enables later change to happen much quicker and with much less difficulty than otherwise. Of course that relies on the nature of the future proofing work that was done originally, but then that is the skill that needs to be learnt.
• The second and potentially more contestable is that designing with future in mind actually produces better design now. It forces me down the road of making things generic, designing distinct interfaces or protocols and, most importantly, building the whole design around a conceptual framework.

This last point about the conceptual framework is critical to the understanding of any system. So long as you understand that everything fits in a conceptual framework and know what that is then you can far easier extrapolate your understanding to areas of detail that you don’t know, than otherwise. In other words, it is so much easier to take a sensible guess. It is also so much easier to understand how you would extend it.

The counter-argument to my whole proposition here is that modern technology and modern methodology make changing systems so much easier than before. For example, with virtualisation tools a server or disk volume can be moved and resized with a single click. Or, with modern IDEs, software can be re-factored with a single command.

However, both of those would be even faster, or perhaps even unnecessary if the design was done right in the first place.

Imagine I am holding my hands out in front of me, two feet apart and imagine that represents all the work an average technical team does. Then think about just how much your customers actually get to see. For me I think that is about the last two inches. So we have all that effort, all the brilliance, all the achievement and yet apart from those in the technical team, nobody ever gets to hear about it.

My answer to this is a strategy for exposing this wealth of hidden experience and expertise. For me this means doing the following two things, running a technical blog and getting people onto the presentation circuit. In this article I am only going to cover the former – the power of the technical blog.

First of all let me get the basics out of the way. Blog software that a whole team can use is easy to come by, we use WordPress and hosting server should be easy for a technical team, but if not then go to a cheap hosting company and it can be yours for a fiver a month. There should be no practical barrier to doing it.

The purpose of the blog is for my team to document the technical things they do that nobody would normally find out about. So that ranges from:

• Documenting that great OS bug they found that required a special patch from the manufacturer
• Describing the correct configuration for that obscure piece of software that they had to struggle to find out
• Recording the results of some testing they did on a new piece of kit
• Sharing the things the things they learnt on a technical conference
• Promoting that great technical idea they have that manufacturers should all be adopting

and so on. I’m repeating myself, but basically anything that is technical and would otherwise not be seen, goes.

I don’t authorise the articles in advance, or even know about them until they are published. If fact, I only have two rules that I ask of people:

1. It must be about a technical subject
2. It must not be too rude

The next step is marketing the blog. Now, provided you are sticking to the purpose above and you don’t want to use it for product marketing, you can simply brand it as a peek into the work of the technical team. Then, link to a relevant article wherever the opportunity arises. In fact it is generally preferable not to repeat too much of an article in another context as people might not follow the link.  I tend to check the referrer stats to see just how much traffic has been generated by the placement of a link.

The trickier element is ensuring that the titles of the articles, the way they are written and the categorisation given, meet with search engine requirements to ensure that our articles appear at the top on focussed searches. But so long as people stick to the plan and write one article at a time then this should get better over time.

Once the initial internal promotion to a sceptical technical team is out of the way I find myself left with very little work to do. I have to remind people, when they are near to completing an important piece, that now is the best time to blog it. I have to check categorisation and add or change categories as needed to cope with the changing nature of the articles. I check the web stats to see what groups are reading it. Finally I avidly check it every day to see if there is something new.

The power of a technical blog is that it makes the work of the team transparent, it establishes credibility for the team, it gives them the recognition they deserve and it builds a community. It also makes great reading. Priceless.