We want project teams that feel connected, where the team members are personally invested in the progress and success of the project, where you feel drawn to get to work in the morning because there’s awesome kicking-ass to be done. This is important, and it’s not down to chance alone… it’s a function of the people on the team, the team culture, the organisation, and the project.

This blog post is about a simple way to use what’s already there on the team, and turn “wanting results” and “caring about the project” up to 11.

There’s more in-depth discussion below, but in brief here are the three things you can do to turn it up:

1. Get your team to see the project in terms of tasks that get done — each one unambiguously and totally and finally completed.
2. Celebrate each achievement actively and constructively by witnessing the achiever re-live the most significant moment of the achievement.
3. Keep aware of motivational debt, especially on a distributed team, and take time during in-person gatherings to pay back the motivational debt through re-living the team’s achievements, and sharing the stories that make up the project’s mythology.

» read more

I help people in technology companies overcome creative negligence.

What is creative negligence? We put enormous effort into recruiting the best people for the job, and we hire them because they’re capable and creative and resourceful, and have excellent experience or we see great potential in them, and yet, invariably we put much less effort into the relationship once they’re hired.

How much of this potentially available creativity, resourcefulness and experience actually ends up being turned towards results for the project or business?

Or how much gets wasted due to micromanagement, lack of connection, not having an environment where people engage fully with their work… and what would working together be like when we have the opposite?

This is what I call creative negligence, and I help identify, prevent and fix it, using improvisation games, coaching techniques, mythical metaphors and the psychology of leadership.

I’ve been working at The Hub in Amsterdam, and I’m offering Hub members 10 minute “speed creativity coaching” sessions, to find delightful new perspectives and get to the heart of whatever you bring to work on.

When you decide to do something important, talk it over with someone else.

In person, in real time, using your voice.

This can work well when you decide to fix a bug in some software, or create a new feature.

Have you ever found yourself in a kind of self-deception where you’ll think you know in detail what you’re going to be doing, but in your mind you’ve glossed over important specifics?

At Jarn, software developers grab a co-worker for a short conversation right after they take a ticket to work on. It takes 5-25 minutes, and acts as a kind of sanity-check, giving the developer a space to talk about the work and see for themselves which parts they’re certain of, and which parts have unknowns.

It’s important that this doesn’t interrupt the flow of the reviewer, who may be deeply engaged with their own work. And it’s important the developer get the review immediately, so he won’t be encouraged to multi-task, and to keep the whole process LEAN.

The team who develop Launchpad at Canonical do something similar. They call it “pre-implementation reviews”. Developers work in five-person squads that work all across the codebase as needed. The members of a squad work distributed, as they live in different locations. When someone takes a bug or feature to work on, they typically investigate, think about it and maybe do some exploratory coding. At this point, they either fix the bug right away, and ask for a code review for the finished work. Or, if it’s larger or more complex, they’ll talk to a squad member over Skype or Mumble before going ahead. This gets everyone being proactive about being unblocked in their work. Squads have daily stand-up meetings (again, over Skype or Mumble) and they’ve found this is a good time to ask for a pre-implementation review.

It’s important to have these conversations in real life, or over a video or voice connection, and not using instant messages or irc. There are two main reasons.

1. A voice conversation allows other concerns to be raised more easily. It takes a lot less effort to answer a closed-ended question in an open way when we’re using voices.
2. The sound of our voices carries words and also emotions. It’s like a second channel of emotional communication that helps us to read between the lines, and allows either the reviewer or the developer to see if the other is not telling the whole story.

For example, perhaps the developer is feeling over-confident. Or maybe the reviewer is concerned, but being polite and not saying so.

Why would he do that? The thing is, not everyone is equally candid, not everyone feels able to raise an objection. Particularly when talking with people who they view as having stronger personalities, more power in the project or company, or who seem smarter than they are.

Opening up the emotional channel gives us two opportunities to listen between the words, and get a full connected and truthful review.