Does your business need an information architect?

Although the focus of my career has remained largely consistent, my job title has changed and evolved. This (I believe) is largely to reflect the needs of the host business. Often the business will place value on one particular nuance of my role. For example a 'usability engineer' will be expected to write reports based on user feedback of a given prototype. This might be necessary because historically, the user interface is produced and executed by your developers yet they don't have the time to evaluated their output. The term 'engineer' also reflects that the business has an engineering bias.

Similarly, a 'creative director' might work amongst a number of design focused roles such as interaction designers or visual designer. This perhaps reflects a businesses design focus. Its more likely to be a customer facing brand and the user interface could be developed via an off-shore team. Hence the need to document the intent of the business and user as accurately as possible.

More recently, I have had an increasing exposure to the job title 'information architect'. I suspect some of you will have heard about this role. Some of you may feel that you are doing that role as part of your current job title and others maybe conducting elements of this role without realising.

The information architect role is nothing new. Indeed this practice has been around for hundreds, if not thousands of years. Perhaps the classic example project being Melvil Dewey's 'Dewey Decimal' system which was conceived in 1873 in order to organise vast libraries of books. The system was widely adopted throughout the world and is used to the present day. I have no doubt that you will have encountered the Dewey system at some point in your studies.

Once you appreciate the Dewey system you will know that books are organised by theme and you will also know that themes are normally arranged in collections on specific shelves. This means that when you are looking for books on African Arts, you are likely to see other books which are also related to the same topic. This increases the chance of what we call serendipitous discovery. In other words, the chances of finding an answer from an unexpected source is greatly increased because of the way the books are organised.

The obvious value in having an information architect in your company is to provide a system like this which organises the information your staff or users utilise on a daily basis. This system should be intuitive and understandable so that anyone can quickly complete their goals - reducing time, effort and therefore increasing profits. The system should also extensible so that it adapts to the growth of the business. Therefore, an information architect will require a good understanding of the business goals in order to establish a flexible and long lasting solution.

In the O'Reilly book on 'Information Architecture', Peter Morville and Louise Rosenfold outline seven reasons why 'why information architecture matters' to organisations:

  1. The cost of finding information
  2. The cost of not finding information
  3. The value of education
  4. The cost of construction
  5. The cost of maintenance
  6. The cost of training
  7. The value of a brand

However, in recent years I feel that the term information architect has been overused and perhaps watered down. Why do I believe this?

Firstly, I often hear of organisations with more than one information architect. Indeed sometimes I hear of organisations with teams of information architects. Imagine if you will, a team of five information architects working on the Dewey system. How do you know that each of those architects will place African Art books in the same group. Indeed, how do would you know that every information architect will name that label 'African Art'. One might label it 'World Arts', 'South African Arts' or 'African Arts & Crafts'? In short, it is the definition of the system which is key and having more than one person working on a system although not entirely impossible, progress will be painfully slow. It is because of this I do not believe any company with more than one information architect is actually providing the true service or impact of an information architect.

My second reason, is around the question of which organisations require the skill of an information architect.

Think about organisations who deal with large numbers of disparate items. Amazon sells numerous types of products, each classified under very different themes or groups. If the items did not appear under the expected labels, the user would not find the product and the retailer would forego a sale.

Google's search engine uses algorithms which classify and label search terms. If the themes were not recognised the search results would be entirely irrelevant to the user. They would not click the link and Google would not generate revenue.

Utility companies (such as Gas and Electric suppliers) with thousands upon thousands of customers will need databases to record their customers. The marketing department may wish to use this information to promotes a new tariff to customers who have been on a specific tariff for for more than two years (i.e. loyal customers).

Its the way this database is structured and accessed which will allow its internal staff to communicate with this audience in an efficient manor.

So there you have three examples of organisations who do require the skills of an information architect. They all manage large amount of disparate data with one or more key users (internal and/or external). They require an understandable system in order to make sense of it.

But here's my concern. Many of the companies using information architects do not have demanding set of deep and disparate data. More so, many of the companies I see using information architects are actually using them as interaction designers.

Graphic design is NOT information architecture

Software development is NOT information architecture

Usability engineering is NOT information architecture

A quote from 'Information Architecture' by Peter Morville and Louise Rosenfold

Some organisations are using information architects to solve high level concepts via the user interface - in other words by producing wireframes for a website and stumbling across the labelling and taxonomies as they proceed. Designing page by page and then going back to edit each page as they learn more about the complexities of the system.

There are numerous problems with this approach. Firstly you only see the parts of the architecture which are visible to the use in any given state (The 'iceberg' issue). Secondly, you won't be able to build themes or access all dependancies. Thirdly, it is an inefficient way of working.

To further the quote above, I strongly believe that interaction design is NOT information architecture. Information architecture has an entirely different focus to interaction design plus you won't necessarily need a dedicated information architect in order to conduct the work. You may already have someone ideally placed in your organisation who can conduct this role with ease. What really matters is that they know the business and the given audience inside out.

So if 'IA's don't really need to produce wireframes, how do information architects conduct their work? In order to establish understandable labels, themes and hierarchies a true information architect will use user research methodologies such as card sorting or website analytics to establish behavioural insight of the intended audience. They will ultimately produce heat maps and matrixes of data perhaps using spreadsheet applications such as excel or numbers. An information architect will rarely touch a wire-framing or prototyping tool, unless they are attempting to present  and promote high level concepts (i.e. via Venn diagrams etc).

For organisations who deal with disparate data, information architecture can be key to your growth and success and whether your business employs an information architect or not, its worth reviewing your methodologies or your job specs to establish: (A) could my business be more profitable with more structured data system and (B) what skills/insight do I have or need to create an appropriate solution.

A designer without a portfolio?!

My old design portfolio This was my first portfolio. It is a beautiful leather-bound A2 size folder with a number of glossy leaves inside. Each leaf has a mounted presentation of a project, painstakingly printed, cropped and mounted by my own fair hands. This example even has hand-crafted embossing!

It was not an easy item to produce, but of course at the time (1999) I was a student looking for my first tentative steps into the design world. My objective was to express my fascination with all things visual and hopefully impress potential employers with my fresh unobstructed (ok, perhaps naive) view of the world.

...and of course it worked. In fact, before my graduation, I had landed my first job as a web designer for the Daily Telegraph..however, from that point onwards my portfolio gradually became a stress point rather than a labour of love.

Why? You might ask.

Throughout my career, I have chosen to work in-house for large corporations. I love business as much as art. When I was a student I loved watching the BBCs 'Working Lunch' and these days I never miss the Bottom Line on Radio 4 or Newsnight on BBC2. My fascination with business (in my view) makes me a stronger strategic designer because I can quickly appreciate the business models or return on investment of a given project. Plus, I love sticking around to see if my designs actually improved the situation of a business...and if they don't, learning about that scenario so that I can correct it and avoid the same mistakes in future projects.

I feel strongly that UxD/IxD is a business tool, yet there is an inherent danger with visual communication that we aesthetically please companies rather than change them for the better. Designers, more than anyone else in a business have the power to propose and influence the direction of a company by simply anticipating an interactive experience which responds to a stated mandate.

Of course, if you are a junior designer or with a visual branding bias, this becomes an important aspect of your work. But here's the problem: projects fail. Not only that, projects fail often. It leaves anyone who worked on them feeling unconfident, under appreciated and under utilised. Anyone who has ever designed for a business in-house knows that interactive projects never follow a strict path from conception to reality. There are other forces at play, such as technical constraints, project budgets, in-house skills, competitors, marketing and yes, stakeholder support.

So as an in-house designer we can react to this in two different ways:

  1. Create a set of visual designs which inspire a 'I want it' answer from a high up stakeholder and risk producing a project which fails.
  2. Or, change the way we operate.

This change is what Don Norman coins as being a 'generalist'.

What use is a 'beautiful' user experience to a company that can't deliver it? Real designs are about influencing change in real scenarios, with real constraints. Businesses need designers who are effective communicators able to work collaboratively with multiple disciplines. Not just purely creative types who objectively beautify a given user scenario.

My experience of 'purely creative' designers is that they rarely last any length of time in a given organisation. They become either frustrated by their desire for creativity or the business finds that they add little value as they are not in sync with the project team.

So, coming back to my portfolio. If I was to show my current work in a curated portfolio it would fail on my desire to show projects which are aesthetically pleasing and may only demonstrate the vulnerabilities of the current business. For example, on a recent project I proposed using 'relative' times for users (i.e. this happened 5 minutes ago) - which is obviously the correct thing to do in terms of user experience because you significantly reduce the 'don't make me think' mental overhead (thank you Steve Krug). BUT, during the project we established that we could only update this time attribute every hour due to limitations of how often we can retrieve this data. This is a really important assertion, because I can now revise the 'relative' time to a straight forward time stamp - which is a more realistic business solution and more likely to win support in the development team. I am continuing the ambition for business change rather than increasing the potential of another project failure.

In summary, in-house design has to embrace the realities within a given business which means you have to make a number of considered concessions to the user experience in order to ensure the project does not fail.

Explaining this story in a visual design portfolio is (in my view) unrepresentative of the work and considerations I have put in to the project. As an experienced interaction designer, I never want to be judged on the final design alone, I want to be judged on the considerations I have made and the impact of the change on the business.

One final point to consider. Companies looking for an IxD or UxD are deluded if they believe candidates will create a bespoke portfolio specifically aimed at their business. Recruiters control the flow of potential candidates and that means that candidates will have next to no time to pull together a relevant portfolio. Indeed, I don't believe that most in-house designers going for interviews are actually interested in getting a new job. At best, most will be tentatively understanding what else is out there in order to establish 'best fit'. In short: it's a two-way street so get the 'who are you' conversations out-of-the-way and then set them a realistic project task. You'll soon find out if they are serious.

Embracing failure

Creating a culture where failure is a necessary and essential part of  product development can greatly enhance the collaboration and motivation of your team. This blog post on Neil Gaiman's blog sums up this spirit up better than I ever could ever hope to. Enjoy...

I hope that in this year to come, you make mistakes.
Because if you are making mistakes, then you are making new things, trying new things, learning, living, pushing yourself, changing yourself, changing your world. You're doing things you've never done before, and more importantly, you're Doing Something.
So that's my wish for you, and all of us, and my wish for myself. Make New Mistakes. Make glorious, amazing mistakes. Make mistakes nobody's ever made before. Don't freeze, don't stop, don't worry that it isn't good enough, or it isn't perfect, whatever it is: art, or love, or work or family or life.
Whatever it is you're scared of doing, Do it.
Make your mistakes, next year and forever.

 

Learning Ruby on Rails: Starting out

Over the years I have developed a deep interest in web development languages. I am in no way an expert, but I do have an complimentary appreciation of most front end technologies. I feel this is essential skill when working with engineers on a daily basis. However, one of the big mysteries to me is the stuff that happens before the front end technologies such as HTML, CSS and JavaScript; namely the middleware and database layers. Whilst I have a basic appreciation of object oriented languages such as C++ plus scripting languages such as PHP, I confess I don't know enough to give me a leg up to establishing those quick wins in a project team.

I am going  to change this by learning Ruby on Rails.

But why rails? The engineering team at Symantec.cloud use the MS dotnet framework, so this might seem a slight tangent. Rails is advertised as quicker way to deploy web apps, with rails scaffolding providing the magic and power to make stuff happen with relatively little effort.

So this means, its a language which I am more likely to develop an interest in over a long term - since I can create apps easily on my own, plus its a little more cross platform and relevant whatever machine I may be using next.

My objective is to develop a bespoke wedding RSVP application. Before the end of January 2012. At the moment, I'm not sure if that is a ridiculous objective - but it gives me a challenge and something to work towards.

To aid my progress I have purchased two items:

Huw Collingbourne's exellent Learn Ruby Programming (in ten easy steps) screencasts (with a fabulous welsh accent) at Udemy and Michael Hartl's Ruby on Rails Tutorial, which I have purchased via my Kindle.

For the moment, these two resources have given me more than enough challenges, but I have no doubt that I will need more in the future.

One thing I have found is that the setting up the initial setup has been a major headache: Heroku is (by default) incompatible with Windows, you can't upgrade Ruby on MacOS unless you have Apples XCode installed, the RVM command is only available on Unix based machines. The list of challenges to a stable and working development environment seems endless...but I'm working through them one by one, with Google as my friend.

The bigger question for me is this. How will my knowledge of Ruby on Rails assist or improve my appreciation of user experience. Will it make me a better designer? Or will it simply distract me from the core principles of user/people-centred-design? The jury is out.

In the meantime, if you have any additional resources which may assist me, please leave them in the comments below. I think I may need them!

 

Don Norman: We need more 'generalists'

I found this speech tucked away in the Q&A section of Don Norman lecture at Stanford University. As usual, Don is completely on the money. However, Its not only only design education that needs to change.

The industry still hires designers as 'artists' - and yes, I believe this is a hangover from the historically focused art & design education. We seem to be in a vicious circle of focusing on appearance alone and its doing little for the reputation of the wider interaction design industry.

Designers should have a broad understanding of technologies and their given audiences/users, but they should also be hired at the right level and be expected to quickly assume a deep knowledge of the business in much the same way as a product manager might.

Of course, we still need the ability to communicate visual concepts effectively, but without an intimate understanding of a given business model or product, our value or impact on ROI is significantly impeded.

Please note: I have edited slightly in places in the interest of readability.

The main principles you learn were (I think) historical, you look at previous designs and you copy them or you change them. Most of Apple comes from Braun (the German company), if you actually look at the iPods and you look at the early Braun products - they are very similar.

I'm not criticising them, in fact Johnny Ive (who is the main designer) is proud of that fact. Because design in the traditional sense is like art in a traditional sense; you learn about the other artists and you learn about them and you build upon them whilst doing your own thing.

...but all thats about appearance and its not about how we use it (interaction). Its not about what we call human centred - so that people can understand how to use it. Thats been big change and that change started with the home computer.

Interaction design started with the development of the first PC's. We started to realise there were psychological principles like feedback, like conceptual models, like affordances, like constraints (etc) that could be applied and thats very far into most designers.

...and today design is still taught as an art. At CMU (technology school), the design department is located in the School of Arts and the Dean is a piano player. At most schools the design is located in the arts and humanities or they are separate design schools (he gives examples). They care about art...design is art.

So we need a new breed of designer and what we now have human computer interaction as a discipline with people really learning to understand how new technologies are evolving and used...and we have a design discipline but they seldom talk to each other...and so the stuff that HCI people put out tends to be ugly. They are not very good at communicating the real principles that they themselves are talking about...and we have communication designers (people study a lot about how we communicate concepts) but unfortunately they don't work with the technologists. So I think that we are getting better, but we need to change our educational practices.

In the university, we pride ourselves on specialists...and the way to be bonafide is to become very specialised and quite narrow (you are really good at this). In the world of business and industry, we have to produce products, and products require expertise across a wide number of specialties - you require generalists. Well universities don't train generalists. Because actually a generalist faculty member would either never get hired, or if they were hired by accident they wouldn't get promoted. Because in any given field they would need letters to see if this was a great person.

We need more generalists. Designers are generalists, but right now they are generalists in art...and maybe on materials - but not enough. I think they need training in social sciences and the technologies. A lot of designers hate technology, they hate numbers.

Where I teach <snip>, the ones who hate technology are the ones who end up in the design department...and in a similar way, engineers hate people. But whats engineering about? Its about designing things and developing things that are to be used by people. And if you look at what modern design is about, its applied social sciences.

 

Embedding a new user experience team

Almost 3 years ago I left Yahoo! and London to embark on my new role at Symantec in Gloucester. I have honestly loved every minute of it...despite the regular sleepless nights! At the time of joining my host organisation 'MessageLabs' had been acquired by Symantec and there were many big changes taking place...I was one of them.

Symantec already had a sizeable user-centred design team (which is excellent!) in the shared engineering service group, but I was the first to be embedded into the Symantec.cloud division. There were no other designers, design patterns or visual assets...hell, there wasn't even any other Macs and nothing on the intranet seemed to work! It was a complete nightmare compared with working at Yahoo! which had a large Mac user base.

I was thrown this challenge (and I am paraphrasing...a little):

Make our complex IT products more accessible to the less IT literate small/medium sized businesses (SMB).

I thought it would be valuable to talk about my experiences of embedding a user experience team into an engineering organisation. I don't confess to have perfected the process of embedding a user experience team into an engineering organisation, but I do feel that I have made significant ground on the challenges I saw at the time.

Misconceptions

We just make stuff look prettier

Its easy to get upset when people think that all you do is, take something an engineer did and make it look pretty. Try to resist the temptation to get into a vigorous discussion with someone about user experience design.

I quickly came to realisation that many folk, just won't get it. You could rattle on about user research, pattern libraries and user flows for as long as you want but all you will do is wind yourself up and probably annoy the person you are talking to. That's not a good place to be.

The best response I have found is, 'Yes, making stuff pretty is part of what we do'. I then leave it until I actually work with them on a project to expose the full spectrum of user experience deliverables.

I am not Jesus and I certainly don't have the talent or social charisma to convert everyone into interaction design 'believers', but what I can do is work hard to show promote its value on specific projects. People get that, consistently and without doubt.

We don't do any work, we are just layabouts

I guess one of the problems with digital world is that you could be sat next to someone and they will never see any of your work because the people you work with are the other side of the earth and on an entirely different time zone.

If we were building a sculpture out of clay in the office people would take probably note. They might not understand it, but they can see effort. Digital work is different, unless you are clicking your mouse and keyboard at rapid pace throughout the day, its almost understandable that folk might start thinking that you don't do any work.

Now engineers are tapping all day. If its not emails, its code. They sound busy and its an accepted or standard mode of business, so they may go around the office and engage in conversation with other engineers about how busy they are. Because we are a smaller team, we can't do that...and there in lies the potential for misinterpretation.

Designers are generally passionately motivated about the work they do for the business and customers. They don't see their work as a chore - they love what they do and why they do it: its customer driven (or socially driven), not technology driven. We are dealing with a the subtleties of of web development making the choices that help our business to be more successful than it's competitors.

I digress a little.

Going back to the title of the section, this is a short sighted comment and those who suggest we are lazy are probably either covering their own tracks or jealous that we love our jobs so much. Ignore 100% or if it bugs you that much, take them into a meeting room and let them know it bothers you. If they persist go to their manager or HR. Its toxic and disruptive.

Everyone seems to name any document we create a 'wireframe'

...and actually, it doesn't matter too much. They can call it whatever they want, as long as the find it useful document to discuss and challenge - that's all that matters.

Visual stuff doesn't take more than an hour to produce

If you show someone a few page designs, they might be tempted to say that it only takes a couple of days to knock up; and of course, they have no idea that to establish the final designs you have to create user goals, user scenarios, user flows, wireframes and conduct user research to validate the approach.

It can be a bit of a chicken and egg scenario: You won't be given the time you need unless they see value, but you can't produce the value unless you are given the time.

The only way I could make this happen was by working closely with product managers and project managers to explain and explore our processes in detail. Make sure you tailor your communications to talking about time benefits with the project managers and quality benefits to the product manager. That is what they care about.

 

Do more of...

Talking to engineers

It is really important to get an understanding of every engineers skills and the challenges they face. They are usually up against some crazy time schedules and you could significantly cut their work load by making small changes to your designs.

Show and tell

When you have a great story to tell about your contribution to a project, tell everyone. In fact tell everyone and their dog! Promote what you did, as it will pave the way for other designers when they work with the same folk. Put the work on the walls, and be prepared to explain what you did when people stop to take a look.

Wiki/Sharepoint use

Making your work available to everyone in the organisation (and at all times) makes a huge difference to collaboration and exposure of our work. You can fire links around the company with very little effort at all. Granted, its a bit of a pain at first to set up project wiki pages and document every change or meeting...but its an impressive resource for all to see.

Clickable prototypes

People love stuff they can interact with and it doesn't matter if its a very linear/strict prototype. Going the extra mile to product a prototype will ensure you get the buy-in you need - guaranteed.

 

Do less of...

Using UX or IA terminology

Pretty much everyone you speak to won't understand words like: Information architecture, cognitive overload and mental models. Don't waste time educating them, make it clear and concise in normal every day language.

Trying to convince people of the value of user experience/interaction design

Some folk are just so die hard against designers, its not even worth wasting your breath, but that doesn't mean you should stop working with them. Always make yourself available and always remain positive. Hold out for the right scenario/situation to expose the value of your work.

 

 

 

 

 

Consistent interaction conventions

Chip and PIN deviceI stumbled across this Chip and PIN device at a petrol station near Swindon last. I was reminded me of a talk by Jeremy Rewse-Davies (Design director of London Transport) some time ago where tube station employees had adapted poorly concieved posters to meet the needs of the public.

Without previously acknowledging it, most Chip and PIN devices across the world have a 'enter', 'OK' or green button on the bottom right-hand corner of the keyboard. This is usually the key you press once you have tapped in your PIN. Often the 'OK' button is larger than the other keys to increase visual impact.

However, in this example - the green key is not in the bottom right-hand corner. It is the same size as the other keys and it is obscurely situated one key from the right; it also incorporates an unconventional 'E' printed on the key.

This entirely breaks the design conventions used on not only on other Chip and PIN devices, but also calculators and other interactive dialogues which instigate a user response.

In this case, the poor petrol station attendant has obviously got a little fed up of folk not being able to use the device and has stuck on a big arrow instructing customers to 'please press'.

When I went to use the device, I immediately ignored the stuck-on note (as hand written notes often incur less authority) and went straight for the 'Fn' key after inputting my PIN code.

I had a little smile when I realised what was going on, but soon got a little stressed when I realised that there were 5 folk behind me in the queue waiting to use the machine.

I wonder what the impact of this design error has been?:

  • Think about how many folk use this device every day.
  • Think about how many times the petrol station attendant has to explain the note
  • Think about how many folk with poor or impaired eyesight get confused by the legibility of the handwritten note
  • Think about how much time is lost as folk incorrectly press the 'Fn' button instead of the green 'E'
  • Think about how much time it takes to decipher the handwritten note and the purpose of the 'E' key.

Point-of-sale technology often assists in improving of customer turnaround... and yet this device seems to disrupt that process immeasurably.

Creative leadership styles

In our fast-paced modern world of web development, speed is of the essence. Indeed, innovation often takes a back seat in order to get 'something' into the wilds. This pioneering spirit allows businesses to capitalise on a new market segment and lead the industry. Myspace, Friends Reunited and Yahoo! all did this to varying degrees of success, but they are all testament to finding a niche and doing it quicker than anyone else.It isn't often you are celebrated for being a good second place! Of course sustaining first place is an entirely different issue, which I may explore in a future post.

This growing obsession with speed often collides with product quality; but it does it have to? Surely there is a win/win situation here? How can we as leaders adapt to the demands of the business without sacrificing quality?

The are two opposing leadership strategies in order to respond demands of the business. Without realising it, we may default into a particular style - especially when working in an unfamiliar environment or with unfamiliar people. It is rare that anyone stays on one extreme of the scale,  so I feel it is important to remind ourselves of the pros and cons of each approach so that we can adapt and change when appropriate.

Command and Control leadership

Command and control is derived from a military style of leadership where it has been used extensively for thousands of years. It is an authoritarian regime where one person holds absolute power and responsibility for the project and people. This enables total coordination and accountability for their subordinates.

Do exactly as I say

This style of leadership is appropriate for tasks and projects where there are uncomplicated simple tasks with little room for human error. A good example of this might be a car factory or a food plants where conveyor belts and other machinery are utilised.

Pros

Many theorists have suggested that command and control is now extinct in the developed world, however there are a few notable leaders who have more than a 'nod' to the command and control style. Steve Jobs has ultimate control and authority over the products that Apple produce. This has enabled disparate disciplines within the company to produce products of exceptional quality. In other companies (such as Microsoft and Blackberry) design and user experience often takes a back seat and encourage a culture of 'engineers are king'. Apple decided to actively enforce a customer focused regime using some elements of 'absolute authority'.

Nick Park of Ardman Animations (Oscar-winning animation studio) has openly suggested that he prefers absolute control over the creative process. This again has enabled a number of quality films each of which feature an unmistakeably 'Aardman' style, an effective way of marketing the companies efforts in a crowded industry.

Cons

The downside of this approach is that communications can become a major overhead. If you have a hundred people reporting back to one person requesting a review or instruction you may run the risk of slowing your company down to the rate of your communications rather than the speed it takes to make your widgets.

Another downside is moral and business flexibility. People who work under these regimes are normally nominally paid and they have very little ability to influence the decisions made at the higher levels. This can incur suffering or neglect when a new change is imposed.

Often, only the leader will get rewarded for the results of the project.

Finally, because communication is often in a silo from one leader to many, there can be little room for exploration or serendipity. Finding the win/win solution between speed and quality will be more difficult and can rely wholly on the insight and experience of the leader...and as any leader knows, information and context is the only way to make 'good' decisions.

If you hear someone on a project saying something like 'I am doing X, but I don't agree with it', there might be a perceived command and control culture and opportunity to adopt a more autocratic style of leadership.

Autocratic leadership

This is probably the most prevalent leadership style in modern industry. It works on the principle that the folk we employ have professional skills whom we empower to make decisions on our behalf.

Do as you see fit

Generally the tasks of these projects will involve a high level of complexity and numerous stakeholders. The employee will be required to make their own decisions and instigate or influence ongoing communications with other members of the project team.

In an autocratic regime, employees will often display high levels of responsibility for the tasks they conduct and are more likely to establish a win/win consensus when faced with unforeseen complexity.

Pros

The benefits of this regime are that employees can show high levels of confidence and motivation around tasks. Moral is generally higher as the project team have a high level of control and influence over the future direction of the project.

Companies will be more flexible and can change rapidly to meet the demands of the industry.

Employees will be paid highly depending on the supply and demands of their skills.

Projects which empower staff will encourage collaboration between (often) contrasting disciplines. This will often result in more ideas and strategies to respond to the project brief.

Loose or vaguely defined projects are more likely to succeed in an autocratic culture as the professionals you employ will quickly seek to fill in the gaps.

Employees are more likely to get rewarded for their efforts.

Innovation is more likely to occur in these teams, but it will often require an astute executive to recognise the opportunity as the empowerment to make it happen may outside the responsibility of the project team.

Cons

Communication can become excessive and may itself kill a project. Project managers may often assist this process by offering reminder of time and schedule during ongoing project discussions (this is another nod back to the 'command and control' style).

Sometimes a consensus may not be possible due to the competing demands of the project team and it may not be clear who can escalate the issue.

Motivation and morale will be important factors in sustaining an autocratic culture and much time and effort must be spent on producing personal development schemes or social events (this enables easier communication/collaboration).

You may unknowingly create superstar 'employees'. High achievers who could become less likely to collaborate with others and  may reduce the moral of other employees.

Conclusion

There is no right or wrong way to instigate a leadership culture within a company. What matters is that you select or utilise the right methods for the appropriate scenario.

If you have bad results from utilising one approach, why not try another? The results may surprise you.

IE6 Countdown

IE6 Countdown

10 years ago a browser was born. Its name was Internet Explorer 6. Now that we’re in 2011, in an era of modern web standards, it’s time to say goodbye. This website is dedicated to watching Internet Explorer 6 usage drop to less than 1% worldwide, so more websites can choose to drop support for Internet Explorer 6, saving hours of work for web developers.

Endless Windows installation pain

http://www.youtube.com/watch?v=vPnehDhGa14&feature=player_embedded I stumbled across this thanks to @tim_weber. Could there be anything more painful than upgrading and installing every version of windows to date? In terms of user experience, its probably one of the biggest hardships in the life of your computer. I'm quite impressed that its possible...but we always knew Microsoft has great engineers.

How many interaction patterns can you spot?

 

Dieter Rams

Lots in the news about Jonathan Ive today. There has been speculation that he is leaving Apple to come back to the UK. Apparently he owns a house in Somerset and would like his children to have a British education.

More interestingly, on Quora I found out that Jonathan Ive's design idol is Dieter Rams. My knowledge of industrial designers is pretty poor, but I found this rather excellent page which talks about his design principles. Having recently created interaction principles for Symantec, I know how hard it can be to find principles that stand up to the test of time ...and to that measure, I really enjoyed reading his.