Thursday, 22 October 2015

The Alphabet Exercise - a ice-breaker leadership exercise

Here is an idea for an ice-breaker type exercise that you might find of value:

The Alphabet Exercise
An exercise used to help people to understand what are the critical leadership attributes that are most important to them.
  • Intro (5 minutes)
  • Get each person to create an alphabet of leadership attributes that are of most significance / importance to them. One for each letter; minimum of 20. (2 minutes)
  • Collate a group-wide super-set of the attributes chosen by getting people to vocalise what they have written down. (10 minutes)
  • Now get everyone to filter their individual lists to identify the 10 attributes that are the most important to them. (2 minutes)
  • Quick discussion: “How did you find that exercise?” (5 minutes)
  • Now get everyone to filter their individual lists to identify just the most important 3 attributes. (2 minutes)
  • Feedback session getting individuals’ perspectives on their list and collating a new group-wide super-set (on a white board etc.) (15-30 minutes)
  • Open discussion on the super-set. (5-15 minutes)
  • Overall time = 46-71 minutes.

I have the material in a PowerPoint / Keynote form. If you would like it, just get in touch!

About the author / copyright.

Currently available for consulting / interim engagements. Please feel free to contact me!

I am a senior Information Technology professional, passionate about service delivery and people engagement, with wide-ranging experience majoring on transformational change and programme delivery at Director level. Proven track record in managing IT functions, organisational redesign, service improvement, programme and solutions’ delivery, and strategy definition and execution. Accomplished in Customer and Supplier engagement, and with an extremely broad International exposure.
Amazon page: blog: material is copyright of Ian Gouge © 2015. All rights reserved.

Wednesday, 21 October 2015

How to move from Chaos to Simplicity...

All too often we can be so beset by things that, to use a well-worn phrase, “We can’t see the wood for the trees”. Often the scale of our problem is not simply in an inability to distinguish timber, but also in that a great deal of it appears to be on fire! In any walk of life - professional or domestic - such situations can be overwhelming.
If we were to seek them, helpful words of advice would be abundant, and some more helpful than others: “Pull your socks up!” - a little demeaning; “Get a grip!” - a little too dismissive; “Focus!” - what else?!
But recognition of the true situation is the first key step - but then so is the final one, that state to which you are trying to aspire. On this journey from where we are to where we want to be - from ‘Chaos’ to ‘Simplicity’ - there are two other logical steps; Order and Completion. The secret of the journey from the dark to the light encompasses these four steps, and there are worst ways to navigate from an unwelcome and unhealthy situation than to use these as your guideposts.
Chaos: The situation where something is essentially out of control, non-optimal, impossible to predict, manage and steer. This is where you are and where you no longer wish to be. And to move ahead, something has to change. Remember the definition of lunacy? Doing the same things over and over again, yet expecting a different outcome…
Order: The situation where there are some controls in place; where we can measure and prioritise. We may not necessarily be doing the ‘right’ things at this stage, but at least we have established control of what we are doing.
Completion: The situation where things get sorted and finished, and where we begin to thin out the trees in our metaphorical wood. Of course completion can lead to the spawning of new things, initiatives, projects and so forth - but this will happen on our terms because we have established control.
Simplification: The situation where we have attained our ‘to be’ goal. We are no longer standing in a burning forest, but rather overseeing a well-managed, neatly laid out plantation; and where we can look forward to planting those new saplings with confidence.
Perhaps this is not particularly radical, but then common sense most often is not. Recognising the situation and the potential journey to be undertaken is at the heart of the battle. 
How do you get from Chaos to Simplicity? What it involves is focus - and probably ‘getting a grip’, the ‘pulling up of socks’, taking ‘baby steps’ and so on. It also demands clarity of thought, the bravery to prioritise and to tackle a small number of burning trees at a time rather than the whole forest.
There are tools to help on the journey, inevitably, but perhaps one of the key ones is the ability to plan - and to plan appropriately. There is a symbiosis between the Chaos to Simplicity journey, and the planning approach I have suggested in a previous post [Plan ahead, yes - but how far can you actually see?].
Chaos = What you can see now.
Order = What you expect to see next.
Completion = What you think you will see after that.
Simplification = What you hope to see in the end.
Try it. Think of one thing that for you represents chaos right now. Write it down - just one line or phrase to describe it. What it would need to look like to be under control? Again, note just one line or phrase. Then how might completion be manifest? And finally, how would you hope the simplified end-game appeared?
If you can do this, then you have the basic DNA of your plan. You can now plan forward from where you are (and there are probably things you simply must do now! What do you need to do to bring Order etc.?). And don’t be afraid to work backwards a little from the end-game too - otherwise you run the risk of being totally constrained by your present situation i.e. you may put the fires out, but never leave the wood!
Whichever route or method you choose to take to escape the burning forest, devising a pragmatic, planned, measurable approach is fundamental. As is doing something different. Don’t fall into the trap of lunacy - be brave and make a change!
About the author / copyright
This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.

Plan ahead, yes - but how far can you actually see?!

I once drove across Indiana. At one point the land was so flat and the weather so clear, I swear I could see the curvature of the Earth on the horizon. I have also driven in less clement weather in the Alps. The way the roads turned then, you were lucky to see 100m in front of you!
In terms of mapping out the road ahead, business can be a bit like that - though more often closer to the Alps than Indiana in terms of visibility! Yet why is it, when faced with such a variety of commercial terrain, we persist in planning for the mid-term under almost any circumstance?
Using the visible horizon as the extent of what I could reasonably foresee, my US drive would have allowed me to plan for the next several hours with a high degree of confidence; but in the Alps, I didn’t even know what was around the next corner!
Businesses  - and especially ‘projects’ - spend an awful lot of time planning. Some plans at the strategic level are of necessity longer-term, aspirational, more vague; a bit like saying that once we’d made it through the Alps our goal is to eventually get to Milano. But the vast majority are focussed on specific outcomes or deliverables; quite naturally, they attempt to define the who/what/when of those outcomes. However, often these plans are created without any reference to how far we can actually see. They attempt to predict activities and results miles into the future, and we kid ourselves that because the plan ‘looks right’, then it is a fair representation of the future and one accurate enough to navigate and be measured by.
All too often, however, we need to re-plan because we haven’t hit the dates in our original schedule. Sometimes this will be down to forces outside of our control, but often it will be because the plan was never achievable in the first place. We’ve planned as if we were driving across Indiana and not about to tackle another twisting mountain road in Europe. Claims that a project has ‘failed’ often misrepresent the truth; the planning may have failed, not the project. I’m sorry, but a constant 65 mph just isn’t possible heading south on the SS33 towards Italy…
Where we have a choice, what should we do? Obviously you need to apply valid context and goals to this. Some objectives will lend themselves to supremely low-levels of planning detail - but most will not. The key is to try and make as much of your plan about the achievement of real and tangible things; things you can see or touch. Time frames will vary too; many of us will have seen the 30-, 60-, 100-days type plan from a new Exec. Whichever approach you take has to be appropriate and work for you, but the scenarios will in most cases by broadly the same: 
Define what you can see ahead of you now - and focus on the key deliverables at the edge of your horizon, mapping out all the tangible and relevant steps in between. If these become increasingly subject to assumptions, risks, constraints and such like, then are they truly on your immediate horizon?
Define what you expect to see next - and concentrate on what the next large deliverables should subsequently be (clue: these will be just over the edge of your current horizon; those things about which you cannot be certain, where risks, assumptions etc. are playing a major role). Spend less time mapping out the individual steps here. As this time frame shifts from what you can expect to see to what you can actually see, then you can build the detail i.e. when the horizon shifts sufficiently to clearly include them.
Define what you think you will see after that - and outline only the major things you expect to deliver at that point (perhaps the 100-day goals in the 30-60-100 example). There is little point putting too much detail in at this stage; as the horizon shifts, the deliverables will gain greater focus as they come towards you.
Define what you hope to see in the end - and in many cases this may end up being the ‘single big thing’ that you need to achieve: cost saving, greater efficiency, a new product, double-digit growth etc. Here there is almost no truly detailed planning needed.
By taking this horizon-based, tree-like planning approach, you can align your plan in accordance with what you can ‘see’, ensuring that you make the most of your precious planning time and deliver a plan that is suitably realistic. And as time shifts, so does your horizon; this makes the plan a constantly moving, living thing - and not just in terms of tracking progress against a fixed set of tasks. It can never be a one-off. Risks change; assumptions are proven true or false; constraints fall away or new ones arise. You plan should reflect all of that.
At the end of the day, planning is like budgeting (which is essentially a plan for cash); it’s just a snapshot in time, and something, when produced, that is almost immediately wrong. 
About the author / copyright
This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.

Friday, 11 September 2015

“Think-Build-Run” - and Insource or Outsource?

For some people the concept of splitting an IT function into logical components of “Think” (or “Plan”), “Build” and “Run” will be nothing more than a fashion statement. There will also be those who are, for personal or philosophical reasons, totally opposed to the concept. For many, especially where the IT function is small, achieving such a delineation may be impossible given an absence of critical mass in one or all areas. 
Yet for others, “Think - Build - Run” will be a logical move, allowing a sharper degree of focus for them, their people, and their business; giving them the chance to drive up quality and drive down cost. It will be, more or less, the IT equivalent of an efficient production line paralleled with some kind of interpretation of ‘Lean’. For these people, likely to be in larger organisations with larger IT functions, it might simply be ‘the right thing to do’.
For those that adopt T-B-R, there is often a follow-on question when looking at the organisational shift to the new model: Insource or Outsource? Whilst this question is, for CEOs and CIOs always there in the background anyway, T-B-R can throw it further into the spotlight, especially if there is a working assumption that the “Run” part is more or less akin to commoditised computing services. And make no mistake, much of it is. But there is a danger in falling for a too simplistic view of the world. Many people might draw an equation between T-B-R and Insource/Outsource in the following way:

But not only is this a lazy interpretation, it is also flawed. The true line of transformation we should be looking at is something like this:

And why is that?
1 - Because you should never outsource very much of your “Think” activity. This is the area where you are closer to the business, where the relationships between IT and its Customers are most critical, and where in-house expertise can add the most value. If you can truly add differentiating competitive advantage to your organisation as an IT function, then in “Think” is where you will do so.
2 - Because, whether we like it or not, a large proportion of the ‘systems’ IT functions “Build” is likely to be unique to that organisation. Either they are bespoke, one-off solutions, or they are customised versions of commercial software offerings - and sometimes very customised! (And don’t forget all the Excel Warriors..!) It is only when you start to get to homogenous, non-differentiating, more ‘vanilla’ kinds of solution that a greater degree of outsourcing begins to make more sense (and Software as a Service [SaaS] can play a role here).
3 - Because you should never outsource all of “Run”. Even if it is only the management layer that you retain, responsibility for the service still resides in-house, and CIOs need people on their teams who hold that passion and accountability. Again the question of the service being truly commoditised comes to the fore, as do things like scale, practicality etc. There are some elements of “Run” that you simply will not be able to do as well as a third party provider (or at all, come to that: think of networks…), but there may be others where there is enough local differentiation to suggest that keeping it in-house just makes sense.
Of course, other factors come into the equation such as cost differentials and arbitrage, the overall size and philosophy of the company as a whole, appetite, previous experience, in-house expertise and talent, and so on. And the feast is a moving one too, with ‘Cloud’ becoming ever more mature, and the whole notion of Bimodal ’Mode 1’ / ‘Mode 2’ projects adding another new dimension to the mix.

Inevitably the equation is a very complex one, and to which the solution is rarely simple.

Sunday, 6 September 2015

Being Agile...

Fashion is everywhere. Fashion introduces new things to us - and recycles the old! Fashion creates product and demand; it generates sales and profit; it breeds need. Even in Information Technology, we love fashion. It gives us the opportunity to create new notions and processes; it is a natural bedfellow with the rapid changes in technology that we are now seeing, inventing new ways to use those technologies and creating new ‘products’ from them.
Yet what we actually do in IT is the same as ever: we teach machines (computers, now of various favours including mobile phones) to take the data we give them and then manipulate and store that data for future processing (more manipulation) or reporting. Occasionally the data is used to control other things, like traffic lights or machinery - or even spaceships and cars! 
Ensuring that we do a good job in building the systems that make those manipulations effective, IT professionals have always invented rules and processes around the development cycle in order to try and make the end product as good as it can be. As technology moves on and the pace with which development can be carried out quickens, the volume of changes and the speed with which results are needed both increase, and hence new models of development are needed.
And so we have seen a progression of methodologies like ‘waterfall’ through ‘rapid application development (RAD)’ and on to ‘Agile’, the current IT panacea for this decade it seems.
Agile software development is a group of software development methods in which solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change. (Wikipedia)
Like many ‘next great things’, Agile will only be as good as the people and organisations that adopt it However, we might be missing a trick here. Should ‘Agile’ not be a state of mind, a philosophy, rather than a methodology or series of formal IT processes? For one thing, if a development team is working in ‘an agile way’ but the rest of IT is not, or the culture of the business as a whole is slow and ponderous, will ‘Agile’ not inevitably fail to deliver as much as it might promise to?
Take the Wikipedia definition above. The “collaboration between self-organizing, cross-functional teams” requires everyone involved to be able to work in the same way. “Rapid and flexible response to change” needs to be in the DNA or culture of the whole organisation; what’s the point in producing IT systems quickly if their prospective users do not readily embrace change?
If we think of being ‘Agile’ as being “the answer” and that it relates just to IT software development, then we are deluding ourselves. ‘Agile’ needs to be part of the corporate culture.
Agile is a cultural philosophy as a result of which decisionsactions and business solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary and incremental progress, early delivery, continuous improvement and the elimination of waste (in all its forms), effective and prompt decision-making, and encourages a rapid and flexible response to change.
OK, I know this version isn’t perfect - but doesn’t it sound much more like the kind of business we would all like to work in?! Isn’t it more inclusive and relevant to all our staff, rather than that minor percentage employed in the rarified world of IT application development? Yes, it might increase risk a little; and yes, it will demand better delegation, more accountability and so forth. But in the end, those are probably good things - and any negatives should be outweighed by overall commercial benefits.
And I expect each of us can think of real, every-day examples of where being ‘Agile’ can bring true improvement - in bottom-line, morale, responsiveness etc.
Why not change the format and content of that monthly departmental meeting so that we can focus on just the critical points and get through it in an hour instead of the four hours it currently takes?
Why not reduce the number of people needed to take a decision to those who are really affected by it so that the decision is made more quickly? And why not make decisions when a) you have 80% of the data needed rather than search for the 100%, or b) when everyone knows what the ‘right’ answer is anyway?!
Why not redesign our organisations to facilitate teams whose sole purpose is rapid response or firefighting?
Why not cull the hundreds of documents and reports we produce and focus on the very few we actually need?
Why not, why not…
Agile as a software development methodology is all well and good, but until we broaden our thinking to embrace more than just IT, we will never get the full potential benefit of taking such a pragmatic approach.
About the author / copyright
This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.

Tuesday, 21 July 2015

What can we in IT learn about Business Systems from ‘Minecraft’?!

From an IT applications’ perspective, you could argue that there is no way ‘Minecraft’ should be a success. After all, in these times of high-powered and sophisticated devices with their stunning graphics capabilities, a game colloquially recognised as “blocky” and without a single non-straight line in the game perhaps should not have taken off at all. Indeed, it is an interface, one might suggest, that is at least fifteen if not twenty years out of date!

But it has been a success - and a raging one at that. Millions of people play it - many addictively. A whole industry and sub-culture has arisen because of it, and we now find some of its exponents - particularly in the world of the on-line video - gaining ‘Star’ status, appearing on TV chat shows, and with more followers than Presidents, Prime Ministers, and Philanthropic and Commercial giants.

So why is that? If we strip ‘Minecraft’ back to some basic level - that of an ‘application’ with ‘functions’ and ‘users’ - then what might we uncover that can be usefully and profitably reflected back into the world of commercial business systems? Where does it ‘work’, and - more importantly - are these factors applicable to our company’s finance or logistics or ERP systems?

Take perhaps the three of the most salient points:
  • It is inherently simple. The components on which Minecraft is predicated - the cube, the straight line, the interface - are consistent and universally adhered to. Whether you are working with bricks, carpet, snow or foliage, the way you work with them is the same; and, with a few exceptions in the area of ‘redstone’, what you can do with them is even more limited. You either put them in place or remove them. Left click or right click.
  • Because of its simplicity, it is easy to learn. Once you have mastered just a few basic concepts, then you are ready to roll.
  • On one level, this simplicity and ease of use could point to a lack of sophistication - but how you play the game and what you can do within it is massively sophisticated, and that is the more important thing. This ability to create your own world from a blank canvass, where no two buildings need be identical and where no two games will ever be the same, give ‘Minecraft’ the addictiveness that comes from seeing your personalised world rise in front of you. “Just one more brick…”, “just one more minecart track…”, “just one more tree…”.
Do the business systems’ we tend to implement in our professional lives mimic these traits? Hardly. We tend to make systems that are massively complex - and as a result, difficult to learn. In areas such as financial transaction processing or warehouse management, the things businesses do - buy stuff, sell stuff, pay bills, raise invoices, put stock away, pick it out again etc. - are, at one level, simple and homogeneous. And yet company after company believes it is “different”; that systems need tweaking to fit their processes. The end result is that we tailor and customise and seek out those final few percentage points of “perfect” alignment - and in doing so, we create a monster.

And it becomes a monster even before the system is ready to use. It takes too long to build; it costs far to much money; and, in taking this approach, we are creating something that, when the software vendor releases the next major upgrade, may once again take an age to re-customise, and again cost a fortune in doing so.

Some people might argue that they are building-in sophistication; that in taking this approach, they are driving value, efficiencies and so on. If that were truly the case, then why is just about every core business processes and major business applications dependant, at some point or other, on data being manipulated in Excel? If we had done such a great job with our highly customised and ‘sophisticated’ applications, we wouldn’t need Excel. Right?

Think about it. Excel is much like ‘Minecraft’. A blank page; a relatively limited number of rules; easy to use - and the chance for us to be creative and build something that a) fits ‘us’ as individuals, and b) meets the needs of ‘the process’ as we see it. Never under-estimate an individual’s desire to make their mark. As in ‘Minecraft’ worlds, no two Excel spreadsheets will ever be the same! [There is a potential pointer here to the future of business applications - but let’s save that for another article!]

So, keep it simple; change / build as little as possible; focus on what’s really important (and what commercially adds value); and engineer something that people actually want to use.


About the author / copyright

This material (text and photograph) is copyright of Ian Gouge © 2015. All rights reserved.

Tuesday, 5 May 2015

Man Management Lessons from the Badminton Court

I have started playing badminton with my two youngest children. At this stage they are, let’s say, ‘enthusiastic’ rather than proficient - and certainly not as good as they are going to become one day. If we can all stay keen and keep practicing, then there’s no reason why they shouldn’t become decent players.

It’s interesting seeing what motivates them when we play. My Daughter’s goal is to try and build the longest rally possible. She gets excited when she beats her last record, and immediately sets her next goal. My Son doesn’t care about long, tippy-tappy rallies; he wants to become ready for battle, and has started to practice mixing smashes with drop shots, even though he’s not that great at either just yet. His motivation is to make his Dad run around; to take him by surprise; to win a point.

They are competitive, of course, but in different ways. Yet it occurs to me that there is much that is similar in what they strive for - and much in this simple example that is directly transferable to the working world and how we interact with the teams and colleagues in our professional lives. These common threads are: achieving goals and self-esteem; feedback and communication; encouragement and praise.

Achieving goals and self-esteem
Both my Son and Daughter know where they want to get to, even if one’s goal is slightly more concrete than the other. They know what good looks like, and - more importantly - they know what it feels like too. It’s probably not the achieving of the goal that is paramount here, but rather how it makes them feel. When my Daughter beats her longest rally by just one shot she is over the moon; she smiles; she bounces. She wants to do it again; to beat it by two shots more, or three. If I can’t reach one of my Son’s drop shots, it’s the same story. That self-esteem is critical. Who doesn’t want to feel great?!

Feedback and communication
They know, of course, that they’re not that good at the game yet. My Daughter knows, instinctively, that she should be achieving much longer rallies; my Son knows that he should be getting more of his drop shots over the net - and that those that make it, should be so close as to make it impossible for me to return them. Because they’re not perfect yet, they need feedback. They need me to make suggestions about how to hold the racket, when to flick and when to power, when to hit overhead and when not. They need me to fire shots at them in different places, at different speeds and angles, in order to give them the experience and challenge to which they can respond and through which they learn - although they might not acknowledge this part just yet! If I did nothing, if there was no communication, no variation, then their improvement - solely by trial and error - would simply take much longer.

Encouragement and praise
And even though they’re not great yet, in order to feed that good feeling and self-esteem, they need to be encouraged. At this stage, they need praise for even the small things - for trying something, even if it is not executed perfectly. It keeps them enthusiastic, bouncing, looking ahead.

Why should the working world be any different? Why shouldn’t these simple considerations apply to the people in our teams, and our peers and bosses?

And of course they do.

Our professional challenge is in part born from the fact that we don’t know our people as well as we know our children, so recognising some of the key drivers is harder; in part, we are compromised by homogenous approaches to HR - through job definitions, appraisal regimes, lack of time, poor communication - which force a uniform engagement model upon us; and in part our problem comes from the fact that we may not be very good at all this people stuff anyway.

So surely, our goal as managers has to be to understand our people better:
  • to work out what their individual professional goals are, what floats their boat, what makes them feel good - and then align that to what we / our business needs from them
  • to work out how best to communicate with them, and what we can do to provide them with the feedback, challenge, and stretch that better equips them to be successful
  • to work out when to give encouragement and praise - and what to give it for

And just maybe we should do this for ourselves too. Who knows, one day we might just be able to produce some decent badminton players!


About the author / copyright

Ian Gouge is widely experienced in business-driven Information Technology, culminating in significant achievements majoring on organisational and process change, and with a proven track record in turning around / re-engineering IT functions. He possesses in-depth experience of change, transformation, IT delivery, customer and supplier engagement, and a broad International exposure. 

He is also the author of management books on the topics of IT strategy and project management, the impact on IT of e-business, and the IT organisation.

This material is copyright of Ian Gouge © 2015. All rights reserved. Any similarity to actual IT or business organisations is entirely coincidental and unintentional. 

Any redistribution or reproduction of part or all of the contents in any form is prohibited. 

You may not, except with express written permission from the author, distribute or commercially exploit the content. Nor may you transmit it or store it in any other website or other form of electronic retrieval system.

Sunday, 12 April 2015

How Do You Take Your Coffee?

Analogies are fantastic. They allow you to portray difficult concepts against a set of real world comparators thus enabling someone to better understand and interrogate ideas. In theories of management, analogies occupy a key station in this lexicon. Let’s take coffee…
In most organisations, ‘Management’ and coffee go hand-in-hand; most meetings start with coffee, are punctuated by coffee, and end with coffee. Often, the most important conversations are those held at the coffee machine. But thinking about coffee in the round provides us with a means of interrogating management styles.
There are a number of different styles of coffee, and - although fanciful - we can parallel them with approaches to management.
Ristretto - a very short, dark, and intense hit, possibly with a bitter after-taste. In management terms, perhaps we can see ristretto as a rapid, no-holds barred, hard-driving, decision-making style, often adopted in extreme circumstances. From a management perspective, advantages of the ristretto approach is that it is ultra-dynamic and things get done in the shortest time possible - but running the risk of doing so in the least elegant or ideal way. Disadvantages? A lack of compromise, perhaps; no prisoners are taken; and perhaps, like the ristretto itself, you can only take so many before you are ‘eyeballs out’, completely hyper, out of control, and unable to relax.
Espresso - also short, dark and intense, but not to the extreme of a ristretto. Espresso management would promote dynamic decision-making also, moving with pace, but in a slightly more refined manner than the extreme and condensed ristretto. The approach still gets things done quickly, with execution the priority above all else; but perhaps there is a little more flexibility and longevity in the approach, although again, after too many espressos, sleep can prove elusive.
Americano - essentially a ‘watered down’ espresso, and with the option of a little milk. On the scale of hard driving, the americano manager will allow the troops a little extra time compared to its condensed parent, and the addition of milk suggests a management style that offers the option of flexibility; more the carrot-and-stick approach than being constantly driven by hard imperative. If quantity is the killer with the ristretto and espresso (in terms of how many hits you can take before it harms you), with the americano it is likely to be volume that is a problem - from a resolution viewpoint, there is only so much you can actually take-on within a given timeframe.
Macchiato - an espresso in a dress. The short, intense hit is still there; results can be dynamic and reasonably rapid; but there is a considerable amount of froth disguising the style. So the macchiato management style can take some time in building up that froth before the ‘wham!’ of delivery. Perhaps slightly less genuine than an americano, the macchiato manager might be in danger of being seen to be just a little duplicitous or inconsistent by the troops.
Latte - here the espresso is bathed in warm and creamy milk. Essentially things still get done, but inevitably they will take a little longer to get over the line. The experience will be softer, less intense; no bitter after-taste; no shock from the coffee hit. In management terms, this would be the most collaborative and engaging style of them all perhaps. But it’s still coffee; there’s still an espresso there at the heart of it, and the manager must ensure that he or she doesn’t lose sight of it if they are to ensure that things still get done.
Cappuccino - the most complex and indulgent of all; espresso, milk, froth, and a sprinkling of chocolate! One of those management styles you probably either love or hate; a mix of hard, soft, bitter and sweet. When it comes off, a cappuccino can be wonderful - but a bad cappuccino is just unpleasant. You need to be an innovative, self-confident and somewhat machiavellian manager to be able to pull off this style effectively. Things will still get delivered, but you might polarise or alienate people along the way.
And finally, cafe au lait - all milk, no substance. A management style like the coffee: at its worst, weak, wishy-washy, bland. Some people would say that this wasn’t coffee at all…
All very fanciful, of course. But the analogy does offer a lens through which to view management styles, to depict or grade how these styles compare to each other, and - crucially - to understand how we prefer to work ourselves.
And the parallel gives us more than that. If you think about coffee, we probably each of us have our favourite from the short list above. In the same way, we each of us have our preferred way of managing - and being managed. If your natural style is perhaps espresso, but your line manager is much more a latte kind of manager, then it is quite likely that you will get frustrated with them because they won’t move fast enough for you. And they are likely to find you reactionary, threatening and perhaps not a little unpleasant or difficult to handle.
Whole organisations can have a ‘coffee culture’ too. Why is this important? Well, it is highly likely that someone who loves their cafe au lait approach will struggle in anything stronger and more intense than a latte organisation. A mismatch of styles, a clash of approach, will be bad for company, manager and employee in various measures.
There are many management definition tools - such as Belbin or Myers-Briggs - that can help to illustrate styles and predict how divergent ones will interact with each other. In all cases, recognition is the first step; tactics to handle disparities follow after that. The simple parallel offered here allows us to start on that analysis journey with a really easy question: “How do you take your coffee?”.


About the author / copyright

Ian Gouge is widely experienced in business-driven Information Technology, culminating in significant achievements majoring on organisational and process change, and with a proven track record in turning around / re-engineering IT functions. He possesses in-depth experience of change, transformation, IT delivery, customer and supplier engagement, and broad International exposure. Also the author of management books on the topics of IT Strategy and Project Management, the impact on IT of e-Business, and the IT Organisation.

This material is copyright of Ian Gouge © 2015. All rights reserved. Any similarity to actual IT or business organisations is entirely coincidental and unintentional. 

Any redistribution or reproduction of part or all of the contents in any form is prohibited other than the following: 

·         you may print or download to a local hard disk extracts for your personal and non-commercial use only; 

·         you may copy the content to individual third parties for their personal and non-commercial use, but only if you acknowledge the author and blog as the source of the material. 

You may not, except with express written permission from the author, distribute or commercially exploit the content. Nor may you transmit it or store it in any other website or other form of electronic retrieval system.