The best boss I ever had—Ed Hahn, who directed Organization Development at Mattel—made it clear: You’re only work colleagues until you get to know each other. After that, you’re friends, acquaintances, or enemies. Work, Ed said, is social.

via Facebook at work isn’t an either/or proposition

Email overload

In this post, Shel Holtz talks about how Facebook is becoming a more responsive form of communication than email. Too often, important messages get lost in your email (sometimes on purpose). I have emails in my inbox which have been there for months just waiting for me to action them one day. I’ve even taken the little red flag off some because I know I’m not ever going to get to them.

Email has been around now for decades. It’s a staple of our information diet and we’ve learnt how to deal with it. We have even developed specific behaviours around email, mainly because there is just so much of it to deal with.

Shel describes a distinct difference with social networks. The difference being that there is a strong desire to respond when a friend contacts you via Facebook, Twitter or other “social” tools.

• Is this just because social networks are still a new phenomenon?
• Is it because the “status update mountain” is still a molehill, unlike the “email mountain” becoming Everest?
• Or is there perhaps something else at play here?

Read more »

After my last post on the differences between technical and adaptive work, I immediately started thinking about the challenges we see around us and tried to pick apart the technical and adaptive aspects. Here are my brief and random thoughts on these.

Read more »

“[T]he single most common source of leadership failure we’ve been able to identify — in politics, community life, business, or the nonprofit sector — is that people, especially those in positions of authority, treat adaptive challenges like technical problems.”
Heifetz, Linsky – Leadership on the Line

In my post about escaping the scapegoat, I briefly mentioned that a leader must be able to distinguish the technical from the adaptive challenges. This is one of the greatest challenges and exactly where things begin. It can be the difference between a deeply moving, positive and long lasting change, or one that works for a while and then crops up again to haunt you.

So, what is the difference between a technical and adaptive challenge and how do you recognise it?
Read more »

When problems hit, we like to fix them. There are many reasons we do this … some people don’t like the stress of an unsolved issue, some are trying to keep their jobs, others like to keep their boss happy, or some are trying to turn the focus away from themselves. Mostly though, we have this amazing natural ability to bring things back to the way they were. Living systems (of which we are one) strive to reach equilibrium. In times of stress we very quickly resort to restoring balance and making things the way they were before the stress came along. Understandable, but not highly effective.

When trying to deal with deep rooted problems, it is easy to focus on technical things that need fixing. I don’t mean technical in the IT/technology sense but rather problems which have a definite answer and can often be solved with experts. This simpler, more logical and easier problem to solve is simply a scapegoat, a cloud that takes our attention comfortably away from the real problem.

Read more »

Shokunin -noun Craftsman, artisan.

I’ve been reading Japanese Woodworking Tools: Their Tradition, Spirit, and Use and this has caused me to start thinking about the connection we have to the tools we use to live out lives. This post is a little jotting down of my current thoughts on the topic.

The author, Toshio Odate explains that a simple definition of the shokunin cannot express the deeper meaning of the word. The shokunin is much more than a exemplary artisan. Odate describes it as follows:

The Japanese apprentice is taught that shokunin means not only having technical skill, but also implies an attitude and social consciousness. [...] The shokunin demonstrates knowledge of tools and skill with them, the ability to create beauty and the capacity to work with incredible speed. The value of an object is dependent on a subtle combination of skill and speed [...] In short, the pride of the shokunin is the simultaneous achievement of skill and speed. One without the other is not shokunin.

Reading this book, I am slowly learning about the shokunin and the way they conduct themselves and their work. In light of this, as I reflect on my own work, I find it quite lacking in many areas. One of these is the connection we have with our tools.

Read more »

This reuters article about Facebook and YouTube at work making employees more productive has been doing the rounds lately. After reading the article, various blog posts, being in a “feedback” style meeting yesterday and then listening to a This Week In Tech episode that mentioned it (albeit only briefly towards the end), a number of threads began falling into place for me.

For me, this issue is more about the duality between your work and non-work self rather than what technologies you’re allowed to use at work. Let’s explore this using two examples …

Read more »

… Primarily because of articles like this one by CIO Magazine. I found this article through Ameel’s website, so hat tip to Ameel for that one.

Every once in a while someone publishes a “nn reasons why your IT project fails” article. Every time it leaves me with some longing for something insightful. In this CIO Magazine article, every one of the 14 tips provided are logical and rational. Each one of them is actionable. Each one of them is also useless.

The only tip which comes close to dealing with the true underlying problem is tip no. 14 on communicating with project sponsors and stakeholders. Even this only addresses it in a very rudimentary way.

What’s wrong with this?

Firstly, the points made in these articles are practical and useful. I believe they have some value. The problem is that they simply don’t go far enough.

As IT people and project managers, we are trained to be operational, logical, planned, rational and ultimately to solve problems. We read material which reinforces this world view of ourselves. In this instance, the article hands us a platter full of 14 problems to solve and some very palatable solutions. In fails in addressing the real hard questions we need to deal with in order to be effective leaders of IT projects.

This article, and others like it, provide us with a convenient scape goat. As long as we do these things (e.g. select the right project team, use repeatable processes, track changes), then we can avoid the real issues.

What about agile?

Agile deals with this partly by making it easier to “go with the flow” and safely absorb the changing nature of projects. Most of the documentation I have read on the subject focuses on creating processes to control and manage. Don’t get me wrong, these are really really important processes to put in place.

Where I fear we trip up is when we implement the processes expecting them to solve or at least help with our people issues. Again, there isn’t much focus on engaging with real people. How do we better relate to them? How do we learn to understand them and their own pressures and needs? How do we “do communication better?”

What should we be addressing instead?

In my mind, the real issue is a lack of dialogue. Not talking. Not listening. Not communicating. But real dialogue. The ability to put your own needs aside and engage on a deeper level with those you are working for. Only when we get to this space will we begin to see significant gains in IT project successes and real positive outcomes.

Often we need to hear things that we don’t want to hear. Often we need to say things others may not want to hear. As leaders of projects, we need to create a space where this can occur. An open, respectful and reflective space.

This is an area that I am only just begining to explore for myself. Because of this, I still find it difficult to explain in words. The area is one studied by Ronald Heifetz and is known as Adaptive Leadership or Adaptive Change. As I find the words and have the experiences, I hope to write and share more about this.

Until then, some of the following articles might help provide some insights for you:

• When Leadership Spells Danger
• Adaptive Change: What’s essential and what’s expendable?
• Adaptive Leadership
• Adaptive vs Technical challenges
• A conversation with Ronal Heifetz – Leadership without easy answers