Converging & Diverging

Production Line

There is a pattern Converging and Diverging in Architectural Lens described as:

Can you channel people so they come together (or split up)?

Example:

Gates (and gatehouses) channel visitors through a narrow opening, allowing a toll to be levied, or to help control potential threats.

Every manager should use this architectural solution in everyday life. This design trick helps to optimize the work flows. Grouping and ungrouping save the most valuable asset – your time.

For example, if hiring three new people this month do your best to have the same start date for all three. Thus, you are able to save time on introductory trainings, adaptation lectures and other activities. You are doing it once for all of them and not three times for each one.

The same technique I would recommend to use with emails. Every manager is overloaded with them. Save your time by building the rules that group emails into folders. Based on sender, receiver, topic, project, distribution list or whatever. Don’t proceed them immediately. Read you inbox once per hour or even less frequent. As soon as your messages are grouped you can work on specific work streams and not on a single email. You have no switch of context. Thus, you are acting more effectively. And you have the picture of the work stream in a one place.

Splitting the single work stream works brilliantly in many cases as well. E.g. it is useful to split one meeting into two in case if agenda has two separate work streams. Even if the list of attendees stays the same. It helps to concentrate, prepare and focus on a single topic. It makes the meeting far more effective.

The same technique is applicable to email writing. You can split an email into two different threads if there are several topics discussed at the same time. And you can merge a plenty of emails back into single follow-up message to outline the list of actions outstanding and focus on an implementation and not discussion.

Disclaimer: be careful when grouping people. It might be perceived unfair. Even if it is not. One consider himself as a unique person. And that is absolute true. Always care about people and their feelings. The same problem when team is jelled and it is pain for them to be splitted. Take care of people. Always.

Inspired by: http://www.danlockton.com/dwi/Converging_%26_diverging

Roadblock

There is a pattern Roadblock in Architectural Lens described as:

Can you put things in users’ way, so they take an alternative route, or adjust their speed?

Example:

‘Chicanes’ can slow down drivers, pedestrians and cyclists; the crossing chicane prevents running or cycling straight across the road.

The same behavior you need from people sometimes. There are stages of the process that people are trying pass trough without paying a special attention. While they are crucial for success. That’s where roadblocks should exist.

For example: decision-making process. A manager gets a task. Finds the first possible solution and starts implementing it. However, you what him to move slowly. His goal not to find a solution but get the best possible one.

You have to put a roadblock here. Just force him prior starting the implementation to create a document. He should describe in one page the solution itself and at least two alternative solutions considered. That will force him to slow down while making a decision and think about an options and rationale. That is exactly what you need.

Disclaimer: there are cases when speed is crucial. The roadblock should be easier to pass then but still exists.

Inspired by: http://www.danlockton.com/dwi/Roadblock

Angles

The next pattern I’d like to talk about goes from Architectural Lens. It’s name Angles and described as:

Can you slant or angle things so some actions are easier than others?

Example:

Some cigarette bins are sold to authorities using the sloping top as a feature, discouraging people leaving litter on top.

This pattern has great use in management. Policies, roles, organizational chart, titles, departments and so on makes the corporate environment rectangular. Everything has a definition and purpose. Unfortunately, it decreases the flexibility.

There are cases when rules set in the rectangular world don’t let you to achieve your goal and do a specific action. Think about changing the angle. It might help.

Let me give an example. You have a new project. You clearly understand that you are the right person to start it. However, if you become a project manager during the kick off your chances to step back are low. Customer will not accept this move. You have a dilemma: whether to let the project start slowly without you, or you do fast kick off and have to take part in it for a long time due to rectangular rules.

The solution is to call yourself an engagement manager and do your job. Don’t care if this title doesn’t exist in your company.

It is nice practice to change your title, organization chart position, role in the project or department name to ‘hack’ the system. This is exactly changing the angle solution. You are forming the layout that makes some actions difficult to make. E.g. if renaming project manager to engagement manager you make it difficult for the customer to keep you on the project for a long time.

Every time you face obstacles due to rectangular policies, job definitions or reporting dependencies think about changing the angle that creates new surface and makes your life easier.

Disclaimer: you should know that most of the people don’t like non 90 degrees things 😉

Inspired by: http://www.danlockton.com/dwi/Angles

Hiding Things

The pattern for today is Hiding things. Original description says:

Can you hide functions or elements you’d prefer people didn’t use?

And example is:

These church hall heating controls have been hidden (leaving only the timer accessible) to reduce errors by users unfamiliar with them

In managerial world this pattern has two major applications. Positive and negative as you guess. Being the good guy by nature I’d like to start with the positive one.

Hiding things is the good approach for writing documents, policies and so on. 80% of long document is a kind of over-complication. The core message usually takes less than two or three paragraphs and is useful for the most readers. Ten more pages are about minor details and facts behind the proposal. Just split your writing into two parts. A short message to fulfill  the needs of most of your users and a number of pages to provide background and details for some of them. Save the time to your readers.

I’m always looking for the executive summary section. In most cases it works perfectly well. All other chapters can be just scanned that saves time.

Unfortunately, the most positive pattern that makes usability happen in the real world becomes the dirty trick in the communication. This pattern is the brilliant way to put something in writing that not welcomed by the recipient. Just let me show several examples.

The first one is about corporate policies. Have you ever read them? The bigger company is the more complicated they are. As the result it is perfect place to hide something. E.g. your company has a policy that allows ordering pizza or taxi on a specific occasion. However, to use them you should find the right regulatory document. Surprisingly, there is no pizza or taxi ordering policy. It is part of a 60-page-long office space regulatory policy. Those who are aware are using the service. Others are suffering from the pattern. Whether it was done on purpose or not is the question to you. Bad author does it accidentally. The good one does it on purpose!

Another usage of this pattern is emailing. There are cases when you need to put disclaimer, notification or fact into the message to cover your back. However, the counterpart wouldn’t ever confirm this information. So, it is your turn to do the dirty Hiding Things pattern. Write the long message with two or three messages in it. Put you tiny message (that is expected to be skipped by the reader) right after the tough and intriguing question near the end of the message and cross your fingers. In 50% cases if not used daily it works.

Disclaimer: whatever reason you have to hide something you should think from the reader’s perspective. The most awful thing is when writer of the document can’t understand the reader properly. Hiding Things is the most dangerous pattern in this case.

PS: If you don’t you like politics and avoid even thinking about dirty tricks you are not ready for anything more intriguing and interesting but a line management.

Inspired by: http://www.danlockton.com/dwi/Hiding_things

Simplicity

Today I’d like to talk on the architectural pattern Simplicity. Original description says:

How simply can you structure things, to make it easier for users to do what you’d like them to do?

And example says:

EcoButton allows a user to put a computer into a low-power state with just one press, making it much easier for users to save energy.

When I look at this pattern from managerial point of view I see that this is the way we should use modern methodologies. E.g. Agile, RUP, ITIL in IT world or Six Sigma or Balanced Scorecard in general management.

Usually, people see the problem and can identify the methodology that should fix it. However, than they fight for pure implementation of it according to the book.

That is the place where problem begins. Any methodology is always too general and universal for your exact case. You solve your problem but bring unnecessary complexity. You are starting to obey new rules that are artificial to your process.

And that is the place where this must use pattern comes. Just make the methodology implementation as simple as possible. Remove every single procedure, document or rule that is not relevant to your case. Try to identify exact subset of the methodology that fixes your problem and throw away the stuff that is not needed.

It is absolutely clear that this sweeping looks like bad methodology implementation. But why should you care? Just take care of the initial problem to be solved. And while removing unnecessary complexity think of the reasons it was introduced in the original concept. There might be something that you are not aware of yet.

PS: God bless people who care about making agile more simple rather than fighting for its purity.

Inspired by: http://www.danlockton.com/dwi/Simplicity

Pave the Cowpaths

Let’s take a look at architectural patterns. There is a well-known pattern of building paths in the parks. Author of design patterns calls it as Pave the Cowpaths and describes as:

Can you recognise the ‘desire paths’ of some of your users, and then codify them into your system, so others follow too?

As an example he provides the following story:

Example: In Tigard, Oregon, residents marked informal ‘neighbourhood trails’ they used on a map, so the city could prioritise ones to ‘formalise’.

A beautiful and clear solution from user experience point of view. However, the question is how does this pattern related to management that we are talking about in this blog. This is the pattern on how to build the right business process in tough to formalize environment.

Just imagine that you have to define processes on a newly created project. By its nature it has nothing common with you previous experience. It has no clear mapping to any classical management solution. And you have no clear vision in your head.

So, you can use Pave the Cowpath pattern. Just let the project live on its own. Define no processes. As you understand in a meanwhile a set of informal business processes will naturally appear. So, it will be the high time to formalize them.

Surprisingly, you might get a brilliant and clear solution. However, usually you get something strange and a bit messy as a result. Whatever you get, you have something to start with. You can polish, improve and redesign the processes but you will have them at least.

Moreover, you will get two guaranteed benefits that are the worth ignoring all the liabilities of this method. First of all this approach does work. Your artificially defined process didn’t block the job. And the second benefit is that this solution is absolutely organic. It has no pretty but useless additions from a management theory. You get the straightforward solution for your exact case. Isn’t it the process you where looking for?

Disclaimer: From the first sight it looks like oriental wisdom about sitting on the river bank and waiting for the corpse of your enemy. Strategically it is exactly the same. However tactically it isn’t. Please, don’t think that you should do just nothing and you’ll get the result. You must be part of the process, you must participate in building it. Do your job as you usually do. The only thing you should not do is to define the process until it is clear and proved to be working.

Inspired by: http://www.danlockton.com/dwi/Pave_the_cowpaths