Influencing change in a bureaucracy

January 18, 2009 § Leave a Comment

It already sounds difficult doesn’t it?

A bureaucracy, as defined by Warren Bennis (1969) cannot cope with:

  • Rapid and unpredictable change
  • The increasing complexity of modern organisation
  • Diversity of specialist experience required in many organisations
  • Humanistic, participative management styles

But before we start weighing up if an organisation is a bureaucratic one, we ought to be able to envisage what’s over on the other side of the spectrum. Well, this then would be an Adhocracy:

Adhocracy is a type of organisation design with is temporary, adaptive, creative, in contrast with bureaucracy which tends to be relatively permanent, rule-driven and inflexible. Adhocracy is similar to the concepts of organic and integrative styles; bureaucracy equates with mechanistic and segmentalist approaches.

I would add that an adhocracy is an organisation that is adept at continually improving itself.

Adhocracy Vs Bureaucracy

Adhocracy Vs Bureaucracy

As a software consultancy we’re often asked to ‘transform’ an organisation from using a set of traditional software practices to more modern ones that we know achieve better results. Taking up some of these practices has direct repercussions on the way that IT departments organise themselves. Having been involved now in a few of these ‘organisation transformation’ projects, I’ve become increasingly convinced that from the outset we really need to get to grips with knowing exactly what type of company it is that we’re dealing with.

For example, as consultants if we go into an idealistic adhocracy our ‘change objective’ is going to be a great deal easier. Largely this is due to the client being used to change anyway; in fact change is part of their way of life and is embraced as such. In this situation we can do what good consultants do best, which is to implement change via a participatory approach. We can engage with workers in the ‘trenches’, and the good practices that we introduce will naturally ‘bubble out’ in an organic way, delivering change across the organisation.

The reality is though that most companies will have some bureaucratic traits in them. In order to answer this, we need to examine the question of ‘how do we tackle organisations that are veering towards being bureaucratic?’

Some consultancies, particularly the one I work for, would wish to encourage a participatory, collaborative way of spreading change through an organisation. By working with employees on a day-to-day basis, we can foster relationships that engender trust, and pave the way for individuals to try out new ways of doing things.

However, we must acknowledge that in organisations veering towards bureaucracy – i.e. ones with virtual ‘walls’ in place that separate out segmentalist units – such ‘organic’ change isn’t going to spread very far. Rather, by working in conjunction with people in the upper layers of an organisation, we will have the ability to propagate change downwards, and to try and possibly move a company along towards being more adhocratic. We can factor this approach in along with the ‘organic’, ‘bottom-up’ one, and so long as we synchronise up our efforts we may get a little more bang for our buck.

Going further, some researchers – Dunphy and Stace (1990 and 1996) argue that incremental and collaborative or consultative modes of change implementation can be highly inappropriate. For the survival of an organisation, where rapid change is absolutely necessary, transformative approaches will be effective when carried out in a directive and coercive manner.

It makes a little bit of sense in the end, that in order to change a ‘heavy’ bureaucracy we have to first embrace what a bureaucracy actually is and to play to its strengths.

Needless to say, if we’re working closely with the upper echelons of an organisation to help plan out a ‘directive’ change strategy, we’ll need to have a robust, comprehensive plan in place. We’ll need to have drawn up a roadmap of actions based on the original business objectives for change, performed an analysis of the major stakeholders, worked out how we’re going engage with the various sub-sections in the company; it’s a big task. Simply placing consultants in varying roles throughout the organisation and letting them work their magic isn’t going to cut it. The approach needs to be cohesive and well communicated.

It sounds somewhat obvious, but it’s really worth stressing that we really need to know up front what type of company it is that we’re dealing with when we’re asked to implement strategic change. An adhocracy? Great. A bureaucracy? Hmm…

Developer Frustration

January 2, 2009 § 3 Comments

There have been a number of times when I’ve sat down to code away at a software problem, and then after a while discovered that I’m getting quite frustrated in some way. If I’m honest I wondered if this was simply me being me, hypothesising that there’s a part of me that just sometimes gets irritated if I’m investing all my efforts to reach a specific goal, and I’m being hindered in some way. It may be that I just can’t seem to go fast enough, I simply can’t do it with the resources at hand (i.e. a deficiency in my own skill-set), or if I’m being disturbed too regularly.

But after spending the majority of the previous year coaching other devs, I’ve realised – thankfully – that I’m not alone in getting somewhat p*ssed off when my best laid plans do not come off in the way that I’d expected.

Why though? I know I’d be happier in my day job if I didn’t get into this arguably ‘destructive’ mindset. I’d be better able to reach that Zen like state of ‘flow’ where the mind is cohesively primed to tackle the problem at hand. I’d be less stressed for starters, and would simply have more fun when I’m doing what I’m doing for a living. Here in this post, I’m going to have a stab at discussing some commonplace frustrations I see in myself and others, and then look at what options – if any – we have for handling them.

Before I go any further, we do have to consider if it’s really that much of a bad thing that we do get frustrated at work. After all, it’s often desirable to be passionate about what we do. Surely the upside to frustration is that we are incentivised to remove whatever blockage is in front of us that’s causing frustration in the first place?

As to avoid getting out of my depth in philosophising what exactly frustration is, I therefore choose to refer to frustration in the terms of creating a destructive mind state, as oppose to a constructive one. This is drawing on a book I read by Daniel Goleman entitled ‘Destructive Emotions’. As he writes “With a destructive emotion, there will always be a gap between the way things appear and the way things are”. From my understanding, frustration will impede us when we consequently start to get bogged down in negative thoughts and doubts. Frustration is a natural emotion, and will happen to some more than others. It’s what it leads to and how we handle it that makes all the difference.

What frustrations are there in IT? Some will immediately argue that they are abundantly obvious. For example, I can vouch that software development can be quite a stressful place to operate in. We are given expectations and deadlines, we are constantly reviewed, we act as guardians to preserve the quality of the code we produce, not to mention that business requirements are always changing, and we are frequently interrupted with various meetings and with a whole host of other initiatives.

Other pressures include those of working in a team with a wide range of available skillsets. It’s very much a part of the day-to-day that you’ll be working alongside people that know much more than you in a given area, or on the other hand with people that know very little and require extra time to get up to speed. Looking at the Dreyfus model, where it is postulated that through the process of skill acquisition we move through five different stages, from Novice to Advanced Beginner then right through to Expert, it is logical to assume that each level comes with it’s own set of nuanced frustrations – as Dave Thomas writes about with level one.

So what’s the best way of handling frustration when it occurs? I wouldn’t claim to know comprehensively what the answer is, and individuals do vary greatly. I can think of colleagues that get regularly frustrated, or of those that possess such a Vulcan-esk like mentality that they wouldn’t seem to be able to grasp what all the fuss is about.

What I would offer is that improved self-awareness of when we are feeling frustrated is a good first step towards making our work-life more enjoyable. A second step is a measure of acceptance; it’s OK to feel frustrated, everyone does anyway so I don’t need to give myself a hard time over it.

Once we’ve accepted frustration, another option we then have is to be explicit to others about how we’re feeling. This is particularly useful in pair-programming. For example ‘I’m getting a bit frustrated with this coding problem as we’ve been at it for some time’, or ‘I’m lacking some understanding here, it’s just not making sense to me’. Being explicit about our concerns gives colleagues and ourselves a chance to invent some options about what to do about it.

I was in a pair-programming mentoring role the previous week where upon my pair immediately said as we sat down to begin: ‘I want tell you up front that I’m not convinced by this pair programming practice; I haven’t seen it to be much more effective and I’m finding it very frustrating’. This guy was much better to pair with than the majority of other developers I’ve worked with. Since I knew how he was feeling I was better able to help make things easier and not to aggravate his concerns. I suspect he was happier as he’d got immediately off his chest what was bothering him, and was able to have a clearer focus on the work we had to do.

All this said, about gaining awareness of frustrations, accepting them and making them explicit if need be, is much easier said than done. Doubtless, it comes much easier to some than others.

Meditation is one tool I know of that can help us to improve in this area. By increasingly our self awareness so that frustrations can be detected earlier, we give ourselves more options for dealing with them. Having a structured work plan is also effective. Making explicit the concept of ‘core’ hours where developers are immune to meetings and interruptions, and having frequent breaks when pair programming will certainly help.

Mainly though, let’s just be aware that software development can be… or is… a frustrating practice.

Where Am I?

You are currently viewing the archives for January, 2009 at Pithering About.