A simple rule

ASimpleRule

I read a few newsletters and articles. Last night Austin Kleon posted his simple rule about:

Don’t think too much about your life after Dinnertime

This made me read his post (linked above) and triggered something for myself. Now Austin is talking about the weird time after work where things can look more gloomy than they actually are. And he’s got plenty of examples. I guess everybody can relate to that when you either reflect on what you’ve done this day or could have done, or should have done differently, or …. Yes, and the more you contemplate about it the more distressed you could get and wake up in the middle of the night thinking about it a bit more.

Stop that. Take a break.

Don’t look at your work email in the evening unless you made a commitment.

Don’t create an expectation that others should watch out for late emails from you either.

Thinking about what you could have done differently is a recipe for despair. Writing down what you need to think about tomorrow is good planning. This was also a topic in my latest Health & safety training at work (ZIP – zero incident process). There we discussed the need for the brain to have a break or it runs ‘hot’ and it is more likely for you to make bad decisions.

This brings me back to what Austin’s simple rule reminded me of.

If you are upset about something, don’t make a rush decision, sleep on it and

Deal with Problems in Daylight.

 

 

Tagging is futile

test-tagsOne of my favourite subjects to talk about is note taking.

Why?

Because by writing things down I remember them much better. Solidifying it into memory. Otherwise lots of stuff is forgotten and simply replaced by the next set of information. “Meeting overload” I hear you saying. Yes, agreed, there is that. If you haven’t got the time to do something about your recent conversation within a certain amount of time, you (or better I) probably don’t do it at all or far to late.

And there begins my filing system.

The reality is I can’t complete all tasks right now and then. Hence the information must be filed in such a manner I can find again. In addition, I like to store related information together with this note.

Since the invention of tagging, I love it! Gone are the times of fixed categories or double entries 🙂 Tagging allows virtual folders and sorting notes, information, and emails becomes a breeze.

GMail got a ++ from me and Outlook is still lightyears behind. I always struggle to remember if I filed the invoice under budget, the vendor, or contracts.

The other view

For some reason I stumbled today across an old blogpost that condemns tagging. It not only talks about the disadvantages of tagging such as the proliferation of tags, the ease of creating variants that actually should be the same, and the lack of control which without doubt is counterproductive to its original purpose. No, in contrast it makes a case for structure and stigmergy.

If you haven’t heard about this before, neither had I. The principle is that we (as in humans) remember things better in context. Hence, consistency or strong association help. Multiple tags are therefore not necessarily helpful. In my invoice example I will very likely find an invoice in either the tags “contract”, “budget”, or “vendor”. Although, I’m very sure I will not find all invoices that way because for some I might have missed the tag “budget”.

What is the solution?

Personally, I still believe tags are fantastic. They do have their disadvantages and the biggest one is how are tags created and maintained. Categories like in WordPress are one method. Artificial intelligence (“did you mean “xyz”?”) like Google searches when you make a spelling mistakes might also help creating the right or better associations. And when tagging is used across an organisation the services of a librarian – virtual or as a gatekeeper – can also be of great help.

The core requirement is consistency. If half of the company is using a folder structure (e.g. SharePoint’s team sites) and the other half wiki pages (e.g. Confluence) the search for information will never be easy. The same is true for a personal knowledge system. And I’m falling in my own trap from time to time taking notes in my trusty paper notebook one day and using OneNote the next.

My work in progress continues…

The Art of Successful Collaboration

Create to CollaborateI have been a fan of collaboration for many years at work. “Many hands make light work”. I hardly questioned that collaboration can actually be a hindrance. Sure, I am – like many – aware if one doesn’t pull his own weight the whole team suffers. Although, I didn’t click what prevents this.

Today I came across this article on 99U by Ron Friedman. Using the example of good and bad marriages as well as John Lennon and Paul McCartney of The Beatles he shows that collaboration comes with an opportunity cost. And if that isn’t paid, collaboration pulls everybody down.

I don’t intend to repeat his examples and arguments, please read the above article for it. No, I want to highlight what to do to make collaboration successful (which Ron does towards the end of the article)

The best (visual) design tends to happens late at night.

Jasper Stephenson, a 10 week intern at Adaptive Path said this in his parting blog post.

If I think back to much of my favorite work, the execution part has come from trance-like zen states where I work until well after midnight — not by necessity, but by nature of having a constant flow of ideas that demand to be realized. There’s much to be said for having a team all present in the same space at the same time and the cohesion of ideas that comes from that, but it’s hard to enter a trance of exploration and creation in such an active office.

And this is pretty much what Ron said about The Beatles. The ideas, the rough diamonds, the blink “let’s do this” doesn’t come from the group huddle. It comes from the inspiration at a “non-busy” spot. Like a shower, mowing the lawn, or watching the waves roll in. Then the first bit of hard work starts, working on the very inspiration so I can explain it to my friends.

The Spark

A blank canvas is not stimulating, having 4 or 6 people staring at a blank whiteboard doesn’t help either. A spark is necessary. Much is said about Brainstorming as an idea generating stimulus. Not so. Brainstorming works when you have a facilitator and a topic. Even better, if your participants know the brainstorming session is tomorrow and they have individually time to think about it even if only unconsciously. Ron Friedman demands “homework is necessary”: [The Beatles] collaborated after they [individually] had gotten a piece as far as they could, and were ready for suggestions.

Collaboration

When you meet to discuss the merits and the foolishness of your idea look at your team. Do they tend to agree? Do they have the same sort of thinking? Do they excel at the same disciplines? Let’s face it, while we like people who agree with our ideas – it makes us feel good!, we learn more if people have different view points, different strengths, and can say so without being blunt but in a supportive manner.

Collaborations are most effective when teammates complement rather than replicate one another’s abilities. 

Summing it up

Collaboration works best when

  • there is a rough idea that is the result of hard work – alone
  • there is a team that complements each other
  • there is a team that prepares for collaboration
  • there is a willingness to critique consciously
  • there is a willingness to accept such critique
  • there is a recognition the final outcome is a team effort

 

 

Internal versus External

Enable or Protect

In many discussions the view of customer  is often cited as a core driver. Organisations have long made a distinction between an external customer and an internal employee. While there is a strong push to only see one customer in recent times, this push comes from a UX (user experience perspective) and “mobile first” perspective.

In this post I’m looking at Information Management from a security perspective. I strongly believe there are differences for employees and customers. In this case customer includes the B2B (Business to Business) and B2C (Business to Customer) elements.

The Internal View

Enable and Protect

Most organisations have adopted a policy of openness and information sharing. Fileserver security is often implemented as open unless specific needs require folders or files to be secured. The latter is usually bound to confidential or sensitive information like commercial negotiations and agreements, NDA (non-disclosure) data, and personnel files. Other information is shared to achieve better re-use of data, enable master data management, foster staff engagement, and nurture cross functional teams.

The element of trust plays a significant role at what level data is shared.

The element of control plays a second level role which data is classified and who is the gatekeeper.

The balance between those two is for each organisation different and largely influenced by what is commonly called Culture and the Industry the organisation plays in.

A good description is “Enable and Protect if necessary”

The External View.

ProtectAndEnable

Customers want to have easy access to their information with the organisation. Repeat data entries is a turn off. If I can’t see what I’ve done previously is also a big no – no. At the same time my information should be protected from other customers or organisations but not necessarily from other employees of my business. For example a third party is working on a project with the organisation, then this information should be shared between the relevant team members of both businesses.

Consequently such external collaboration is often implemented in closed groups or spaces where membership is controlled. This model requires a much closer attention to detail and review of membership in particular when staff on either side move to a different business or part of the organisation.

Trust and Control play again an important role, although the weight towards control is much larger and often reversed to the Internal implementation.

The description here would be “Protect and Enable where appropriate”.

How a junior staff member can review the work of his senior

Jedi Master and ApprenticeA story

There is a small team of 4 developers. These guys are very different from each other.

John is experienced and worked for more than 15 years with the company in different roles. His mantra is “never change a working approach”. He preservers the status quo.

William has the same level of experience in the company but has developed a love for the latest “best practices”. He is always on the look out how to improve things.

Mary is with the company just for a few years and then fresh from University. Some of the “old stuff” she is dealing with is hurting her sense of “doing it right” albeit she acknowledges it works. Refactoring would make maintenance and support easier but would have no visible benefit for the end user.

Alan joins the team and it is his first job. He likes the solid and calm approach from John, the energy from William who always seem to find a way to make stuff better for the customer, and the quick thinking Mary who knows tech stuff in and out.

The team leader struggles at times to get them working together effectively. 2 pairs emerge initially, William and Mary driving change with John and Alan asking, isn’t it working fine? Both have very valid points and the team leader would love to get more synergy going and not risking confrontation between the pairs.

Several approaches come to his mind and he settles on breaking the pairs up by switching the 2 younger members around. To get the learning going he asks the pairs to review their work. One of the older guys, John, has a problem with that as he feels Mary being “too cocky” about the old and well proven way he does things.

The team leader remembers a story he heard once how an airline handled a similar challenge. He takes John and William for a walk and explains to them the idea. He asks them to purposely insert some mistakes in their code. That way there is no loss of face, even if the younger guys find things that were made accidentally. He also tells the younger guys so they know there is no conflict between reviewing code and not making friends with team mates.

This approach can be refined to address the different ways of coding, create appreciation of a new way of doing things as well as proven methods.