NOOP.NL

People Don't Listen

Yesterday I had a craving for "kapsalon". It is a local delicacy consisting of french fries, shoarma meat, lettuce, and cheese, all crammed together in a small aluminum tray.

It looks like barf in a bin, though I think it actually tastes better.

When I order a "kapsalon" the standard reply from the guy behind the counter is: "Do you want hot sauce and garlic sauce with that?" When I answer "yes" then everything is fine. But yesterday I tried a slight variation on that. Here's what happened... (real story!)

Guy 1: "Do you want hot sauce and garlic sauce with that?"

Me: "Yes, but I want only a little garlic sauce."

Guy 1: "No hot sauce?"

Me: "Yes, I do want hot sauce. And I want garlic sauce, but not much."

Guy 1: "You want MUCH garlic sauce?"

Me: "NO, I want a LITTLE garlic sauce."

Guy 1: "Ah, ok."

So guy 1 starts preparing my "kapsalon", and after a while he is joined by guy 2, who, for some reason, thinks guy 1 needs a little help. When the two of them have almost finished my simple order, guy 2 takes over:

Guy 2: "Do you want hot sauce with that?"

Me: "YES, I want hot sauce!"

Guy 1 to guy 2: "But he doesn't want much, only a little..."

Then I decided to give up. I saw no point in me discussing the difference between hot sauce and garlic sauce. I simply accepted that the world has many people in it who prefer talking over listening. I took my "kapsalon" with me, and at home I tried to ignore the fact that my meal contained very little hot sauce, and no garlic sauce. It almost tasted like barf in a bin.

Now, I would love to present this as a metaphor for people in the workplace, whether they are managers, employees, customers, or team members. But why bother? For those for whom my message is intended, it would probably fall on deaf ears anyway.

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Managing != Coaching
I Don't Feel Like Writing, Yet I Write
How to Make People Behave: 6 Levels of Disciplinary Action

To See Is to Follow

Today I started following Ashton Kutcher on Twitter. I didn't really think about this decision for long. It's just that Ashton is the first person in the world to have 1,000,000 followers on Twitter. So, except for the looks, there must be something interesting about this guy, right? I don't know what it is yet, but I'll just go with the flow, and I'm sure I will find out.

Ashton Kutcher is visible. Stories about his race with CNN have been all over the place. For someone reading social networking blogs, it was very hard not to see this. That's why I followed Ashton Kutcher.

So, how do you make people follow good practices?

Easy. Make them visible!

In our organization we are fortunate to have an open office space. Last year we introduced big visible charts in the form of task boards for every development team. Anybody walking around the office can easily see them. So, when other (non-software development) teams noticed these task boards, they wanted them as well! They saw and they followed.

This principle doesn't just work for big visible charts. Any visible process is an information radiator.

We do our stand-up meetings in our open office space as well. We first considered doing stand-ups in a more secluded area, so as not to disturb our colleagues while discussing our projects. But we decided against that. (Our people simply try to argue at a caring and considerate volume.) Then it turned out that, again, other (non-software development) teams started following the same practice. They saw the development teams doing stand-ups every morning, and they decided to try this interesting practice too.

To see is to follow.

People copy each other's behaviors, often for no other reason than just seeing them. It's a human thing. It's why I started following Ashton Kutcher. It's why teenagers start smoking. It's why people have more trust in other people when their own behaviors are being copied. Scientists say humans often mimic each other unintentionally. And they also confirm that "mimicry has a tremendous potential to be used as a tool for influencing interpersonal persuasion and communication."

You can use mimicry to your advantage by making sure that good behavior is visible. If you want people to write better code, then plaster the best code you have all over your coffee machine. If you want other people to follow Scrum practices, then post times and locations for sprint planning and review meetings on your company's public calendars. If you want people to use proper source control and branching techniques, then draw the source control tree and its branches on your office walls.

People follow what they see. You must show what is good, and hide what is bad.

And don't post examples of bad behavior in your office. People might (unintentionally) follow them!

Note: By amazing coincidence, while I was writing this blog post, my music player selected Follow Me (by DJ Lange) from my music library. It is one of the most amazing classic trance tracks I have in my collection. So, please follow me, and listen to Follow Me as a great start for a nice and sunny weekend.

(picture by ^riza^)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Islands in the Stream
Great Managers Have No Secrets
Embrace Diversity, Erase Uniformity

How to Do Things Your Customer Didn't Ask For

Some time ago I got a question from Sebastiaan, one of my colleagues. He told me he was struggling with an important issue:

Should we spend time on things the customer didn't (explicitly) ask for?

Here's his full question:

Hey Jurgen,

I am curious about one aspect of Scrum that I don’t really like. Right now we have acceptance criteria and we adhere to them strictly. So strict even, that we’re now starting to say [to the Product Owner]: "No, we are not going to do this, because it is not in the acceptance criteria."

However, a lot of times, we know that this will mean one of two things:

• rework later;
• customer not dissatisfied, but not extremely happy either.

I think part of the reason that we get return customers is not just because they got what they wanted, but also that they got more than they bargained for, with minimal effort on our side. Sometimes you just want to add some real value to the work item that you’re busy with, that will only take an extra hour and will “wow” the customer. How do we deal with that in an agile/Scrum way?

Sebastiaan

This question was so interesting that I had to think about it for six weeks before feeling able to reply (sorry Sebastiaan). Anyway, here are my thoughts:

The underpromise, overdeliver principle tells us that we should manage our customer's expectations in such a way that we are able to deliver more than the customer asked for. It is easy to see why this works. You save yourself some slack in case things go wrong, meaning you have some time to solve any problems. But if things work out well, you have some time left to do something extra for the customer, assuming (note I'm stressing the word assuming here) that the customer will be pleasantly surprised with the extra cherries on top.

The question of how best to satisfy customers has been described in the Kano model, published in 1984 by Dr. Noriaki Kano. In Implementing Lean Software Development, Mary and Tom Poppendieck wrote this about the Kano model:

Kano noted that increasing performance [implementing more features] gives linear results - customer satisfaction is increased in direct proportion to the increased performance. To get an exponential increase in customer satisfaction, you need to discover and meet unmet needs and thus surprise and delight customers. Kano said that great products do not come from simply listening to what customers ask for, but from developing a deep understanding of the customer's world, discovering unmet needs, and surprising customers by catering to these needs.

So, does that mean that the team should build what they think will delight the customer?

Absolutely not!

As Kano pointed out in his work, it takes deep understanding of the customer's world to understand how to delight a customer. The average team member is usually too far away removed from the customer to really understand her world. That's why there's a Product Owner in Scrum. The Product Owner represents the customer, the users, and any other external stakeholders. It is the Product Owner's job to deeply understand the customer's world. It is the team's job to deeply understand the technological world. Together they should be able to build a product that will delight the customer.

(Of course, it is even better when the team tries to understand the customer's world, while the Product Owner tries to understand the technological world. But never should a team be allowed to implement features without asking.)

A year ago, in my blog post Oh My God, They Killed the Bug (You Bastards!), I blogged about someone having solved a "problem" in my car that I didn't want to be solved. I had a rotating knob on my gear stick, but when my car was returned to me the knob was fixed. It was a fine example of a technical team trying to understand my needs as a customer, and attempting to overdeliver by (literally) fixing something that I had not pointed out as a problem. They completely missed the mark, and I was furious. I had grown fond of my silly old rotating gear stick, and it took me a month to get used to the new situation.

The road to hell is gold plated with good intentions...

So, here's my 4-step guide to delight your customers:

1. As a team member, while planning a new sprint, make suggestions to the Product Owner about things that you think might delight the customer. Don't feel bad if the Product Owner doesn't agree with your suggestions. He is supposed to understand and speak for the customer. (But I'm sure the Product Owner will appreciate your ideas.)
2. When the Product Owner asks for a change during the sprint, and when you agree that the change is a good idea, then do it! Who cares if the changed feature wasn't listed among the acceptance criteria of the sprint? Agile is about "people over process". If the people involved want it, then it must be good. Sticking to acceptance criteria is a process. And process is for wussies.
3. If, during a sprint, you have a great idea that you think is worth doing within the sprint, talk about your idea with the Product Owner first. Don't assume he is going to be pleasantly surprised later during the sprint review. I'm sure he will be even more pleasantly surprised if you contact him first and ask him if it's OK to spend some time on your suggested change.
4. If, for some reason, the Product Owner is unavailable, and you think implementing your idea now will save you serious problems down the road, then do it. But make it reversible! Try to delight the Product Owner as soon as he is available, but roll back the change if it turns out he doesn't like it.

Fixing the knob on the gear stick in my car was not on my acceptance criteria. I probably wouldn't have minded the technical team "fixing" it, if they had shown immediately what they had done when they delivered my car. And if they had been able to "unfix" the gear stick before the color of my face had turned shiny red, I would have been delighted at their proactive, communicative and technical skills.

(pictures by nutmeg and mccun934)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Great Managers Have No Secrets
Communication = Information * Relationships
Oh My God, They Killed the Bug (You Bastards!)

The Optimal Team Size is Five

What is the optimal size of a team?

People have been trying to answer this question for ages, and there seems to be little consensus. At the SPA 2009 conference this week I attended a very inspiring session by Joseph Pelrine, who told his audience that the sizes 5, 15 and 150 have been mentioned in (or can be derived from) scientific research, as being optimal sizes for social groups.

The agile movement, with Scrum as the leading method at this time, often mentions a preferred team size of 7 plus or minus 2 (which is just a software developer’s way of saying between 5 and 9).

And recently I read about the results of interesting new research into optimal group size for decision making, which revealed that anything below 20 can work well, except 8. That’s because eight people frequently find themselves in a deadlock situation on their decisions.

Considering all this we can easily see that there’s only one optimal team size that satisfies all research.

Five

Five is one of the three preferred sizes mentioned by Joseph Pelrine. Five also falls within the preferred range of sizes for agile teams. And five is less than 20, yet unequal to eight.

Five is also my lucky number. It is my default answer to any question that I am unable to answer without more information. Five is my personal 42.

You see, I really can’t tell you what the optimal team size is! Here’s why…

In his SPA 2009 session Joseph Pelrine wrote Kurt Lewin’s equation on the whiteboard:

B = f(P,E)

It means: a person’s behavior is a function of the person and his or her environment. My own version of this equation would look like this:

C = f'(P,E)

It means: a person’s communication is a function of his or her personality and the possibilities that the environment allows for. And when we’re talking about a whole group of people, it might look like this:

S = f’’({P},E)

Meaning: the optimal size of a team (being a communication issue) is a function of the set of people’s personalities and their environment.

The value of S can be anything! The precise optimum for team size depends on the people and their environment. Statistically it is more likely to be five than eight (though eight is possible). And the optimum is probably more likely to be between 5 and 9 (for software developers: 7 plus or minus 2) than between 10 and 20 (for software developers: 15 plus or minus 5).

So, what can we learn from this?

My suggestion: when you need to structure a big project, don’t impose a “preferred” team size on people just because it is written in a book. Try to allow self-organization to do its job and let the people (within their real environment) figure out what their optimum is. Do they want to cut a team of seven into two teams of three and four? Sure, why not? Are they merging two teams into one big team of fifteen? Fine, let them see if that works. And be aware that they might want to reconsider things when the environment (or the set of personalities in the team) changes again.

One word of warning: you may want to question their decision when they come up with a team size of eight (plus or minus zero).

(pictures by Budlife "busy" and ooOJasonOoo)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Your Project Has No Goal
Communication = Information * Relationships
Real Agile Teams Can Flock

Islands in the Stream

I recently endorsed the use of Twitter in our organization. I must have been mad. There's already so much information going around, what possible benefit can the noise on Twitter bring to improve our in-company communication?

We receive dozens of emails every day, sometimes directed personally, but often as part of a Cc-broadcast, or a company-wide announcement or newsletter. We use instant messaging in the form of Jabber, and we have phone, Skype and X-Lite for voice transfer. And there are tools like SharePoint and Team Foundation Server that add to the information flows as well.

And of course, meetings...

There are the usual bunch of Scrum-based meetings: planning meetings, stand-up meetings, demo meetings and retrospectives. But that's not all. Most managers organize one-on-ones with their own people, and they have management team meetings, while other people attend functional-level meetings. And we should not forget our regular Academy sessions for self-development, and quality improvement sessions for organizational learning. Oh, and did I mention our business update sessions, where we assemble the whole organization for company-wide updates?

On the other hand, some of the most powerful information channels are the informal ones...

People use pair programming to exchange ideas and knowledge while doing their jobs. They keep themselves informed with blogs, RSS feeds, and shared bookmarks. The annoy the office police by hiding our beautiful office behind posters, whiteboards, and sticky notes. And they elude management's attempts at top-down information control by doing a fair share of their communication during their coffee, lunch and smoke breaks.

Did I forget any?

Yet this still wasn't enough, and I started promoting Twitter. Here's why:

1. Every organization has islands of communication. Some information doesn't travel across these islands because the type of information is not carried easily on the flimsy strands of communication between those islands. Twitter can help here. It told me about @lemoentje's new blog, and which of our employees have been in @roelsn's bath.
2. Our company itself has been an island in a stream of information. There's a lot going on in the world that our people didn't know about. Twitter helps to alleviate this. Twitter was the first to tell us about Google's GMail problems, tips for Product Owners, and the plane crash at Schiphol.
3. And to be honest, a company that designs and creates web solutions, and that carries the word innovative in its name, cannot afford not to be on Twitter. It's the fastest growing social phenomenon on the planet!

So far it seems to be working. Our people are sharing tips, bookmarks, questions, and personal events. The Twitter adoption level in our organization has grown to more than 30% in a short while. I even heard people suggesting to use it for official announcements (which I argued against).

But doesn't Twitter add to the information overload?

Sure, but only if you allow it. I've never heard of a project failing because of too much information. It's always little or bad information that's at the root of problems. And besides, it's useful to be among the first to know things. (My friends on Twitter already knew this article was coming...)

So, how do I join this twitter stuff then?

Well, I just told you there's plenty of information available. Why don't you try and find out?

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Don't Waste Your Time with Twitter
Communication = Information * Relationships
How Smart Managers Think

Optimize Communication, Throw the Boss Out

It is well-known that difficult goals are best achieved when people work in small teams of under ten people. Various agile methods were created based on this principle. Communication in teams is optimal when the lines are short. But that doesn't tell you how to structure an organization with hundreds or thousands of people. The solution of simply dividing them into many small teams is clearly insufficient. How do all these teams fit into a bigger picture?

How do you align many teams to work towards a common goal?

Management hierarchies seem to be a necessary evil. In this blog post I will not waste time on bashing such hierarchies. Everybody already knows that management hierarchies have a bad influence on information flow. (You can read Malcolm Gladwell's book Outliers, and see that there is a strong correlation between plane crashes and hierarchical cultures.) Of course, that doesn't mean that we should not have managers. As I discussed in earlier posts, some people are needed to point dozens of teams in a proper direction. (And I need to have something to do, besides blogging, and sipping tea.)

Let's see what my requirements for an ideal organizational structure would be:

1. Every person in the organization is part of a team. Nobody is responsible for doing something on their own;
2. All teams are cross-functional, meaning that they are formed around (sub)goals, not around expertise;
3. Every person is managed by a functional manager who has full understanding of the type of work being done;
4. Finally, any emerging hierarchy should be as flat as possible. The fewer steps from top to bottom, the better.

What would such an organization look like?

Well, that depends on how you solve the subordinate-manager relationship. Basically, there are two main options (with some small variations that I'm going to ignore for now):

1. One boss is assigned to the team, and manages all members of the team. The boss is part of the team, though he could be managing the team from a distance. This is the traditional department-with-a-boss solution.
2. Several bosses are assigned to the same team, and each manages only some of the team members. The bosses are not part of the team themselves, they are all managing from a distance. This is the modern matrix management solution.

Some people claim that option 1 is the optimal solution, because it keeps communication lines between team members and their functional manager short. When the functional manager is part of the team, he knows all that's going on, which is clearly not the case with option 2, where it takes a manager more effort to understand what's going on inside the teams. It is also said that the matrix management solution of option 2 can lead to conflicts between the functional managers who are managing people in the same team. And it can also lead to conflicts between functional managers and informal team leaders, or project managers within the team.

Still, I believe option 2 is better than option 1. Here's why...

This is a picture of option 1:

The picture shows you a situation where every team has a functional manager inside the team (level 5+6). But who is managing the managers? Well, that will be other managers operating from within their own teams. And those teams have their own manager as well, inside the team (level 3+4). The top level is the company's management team, which also has a boss inside the team (level 1+2).

In the example above, where people are organized in teams, and each team has its own boss inside the team, you end up with a 6-level hierarchy.

Now let's see a picture of option 2:

This picture shows you that there is no boss inside the teams. Instead, each team member is managed by someone in another team, one level higher. No functional manager is part of the teams of his subordinates. In fact, each manager can manage people in several teams, while each team itself can have a project manager or informal team leader. But the project managers and/or team leaders are just "first among equals". They are not functional managers. They are nobody's boss. The team at level 1 is giving direction to the teams at level 2, and they in turn are giving direction to the teams at level 3.

In this example, when the boss is not inside the team, you end up with a 3-level hierarchy!

As Chief Information Officer of our company I have just two concerns: optimal communication, and nice tea. A 3-level hierarchy is much better than a 6-level hierarchy. Therefore, option 2 is my preferred solution. Of course, I understand that matrix management can bring some (small) risks, but I think these can easily be managed. And I'm only painting an ideal picture here. Compromises may be necessary, depending on the situation.

I also know that several other options for organizational structure are available, but I'm sure they all break one or more of the four requirements I listed earlier. So I will happily ignore them, while pouring myself another cup of sweet Darjeeling.

(picture by Orange Beard)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Your Project Has No Goal
Communication = Information * Relationships
Real Agile Teams Can Flock

Don't Waste Your Time with Twitter

I'm a Twitter fan, like many others. But besides tweeting, I also like reading, writing, eating, coding, socializing, and ehm... sleeping. This means that I need to manage the time I spend using Twitter. This need has further increased now that I crossed the 4-digit boundary of 1,000 followers (and friends).

These are my 4 Tips on How NOT to Waste Time with Twitter...

For this article I will assume that you're using TweetDeck. It is the number 1 Twitter client in the known universe. If you're a serious Twitter user, and you're not using TweetDeck, then either you don't have other hobbies, or you follow only three people. (In both cases, this text won't apply to you. In all others, it does.)

1) Dramatically Reduce the Interruptions
Do you have a good reason for checking your Twitter stream every two minutes? I don't. Regularly checking my streams is just like checking my email, getting coffee, relaxing my eyes and arms, and visiting the small room. These activities interrupt my regular work, and interruptions are bad. Oops, wait a minute. WorkRave is now demanding that I relax my eyes and arms...

(stretch... stretch... blink... blink...)

There you go. You see? This interrupted my work. Interruptions kill productivity. It's the same with Twitter. It's a great tool, but you should not allow it to damage your productivity! There are two things you can do about it: dramatically reduce the number of notifications that you get from TweetDeck, or turn off notifications all together. I prefer the first, because I do want to be notified about potentially interesting tweets. But not every minute. There is an option in TweetDeck that enables you to reduce the frequency with which it fetches new tweets. You can find it under Settings, Twitter API:

Has any of you noticed that I only pay attention to Twitter every 10 minutes? Of course not. Twitter communication is asynchronous, just like SMS. I can choose to reply to a tweet from half an hour ago, and I may get a reply myself another twenty minutes later, and we are all OK with that. Tweeting is not chatting!

(Note: It appears that the Twitter API settings do not apply to Search columns. You still get frequent notifications for search results. Turn off notifications completely when Search notifications keep disturbing you.)

2) Focus on Your Favorite Topics
I use Twitter to know what's going on in my business. I don't need to know the latest scoop on Britney Spears. And if you're also serious about your use of Twitter, then you will have some topics that you find most interesting.

TweetDeck allows you to create columns for search results (with the Twitter Search option). I now follow everything that people tweet on the topics agile and scrum. But you can replace that with searches on politics, automatonophobia, strawberries, or whatever.

There are many people who solve the issue of focus by following only a limited number of people. But I believe that is the wrong approach. First of all, TweetDeck has a groups feature that you can use to organize multiple collections of interesting people. (And some people are just more interesting than others.) Filtering streams on your client is much more powerful than filtering streams in the Twitter repository. Second, I want people to be able to send me direct messages. For me this is a matter of politeness, and it is the main reason why I follow most people back. It doesn't mean I'm going to read all their tweets. (I won't.)

3) Prioritize Your Groups from Left to Right
People read from top to bottom, and (in most countries) from left to right. Journalists make sure that the lead of their stories (the first one or two paragraphs) accurately reflect the rest of their articles. That way people can stop reading after a couple of paragraphs, and they still come away knowing the most important facts. Therefore...

You should organize your TweetDeck columns based on importance.

For me, the column with Replies is most important, because these people are talking to me (or about me). Next I have a column named Gurus (industry hot shots), and a Search column (my favorite topics). That's how I know what's going on in my business. This is followed by the column Colleagues (people I work with), Contacts (people I know), and Celebrities (people to talk about). Finally, I have an All Friends column (off-screen) that I rarely look at, and a Direct Messages column that I never look at (since I get those in my email box anyway). You see that I prioritized these columns from left to right based on their importance to me. I do this to make sure I can scan tweets from left to right, and stop scanning somewhere halfway when I lack the time. I always start at the left, and no matter where I stop scanning, I will know I have spent my time wisely, by focusing on what's most important to me.

(My colleagues will be interested to know that I find them less interesting than industry hot shots and my favorite topics. But I'm sure they will be glad to see I find them more important than Stephen Fry and John Cleese.)

4) Clean up Everything You've Scanned
Many time management gurus point out that we lose time re-scanning things we already scanned before. Speed reading is based (in part) on forcing your eyes not to re-scan the words you've already read. Getting things done is based (in part) on forcing yourself not to re-think tasks that you've already thought of before. And well-known productivity tips include maintaining a clean email in-box, so that you don't re-read your emails. The message here is simple...

Don't re-scan your tweets!

Do you see the difference with the previous screen shot? This one only contains unseen tweets, the ones I got in the last ten minutes. There are tiny buttons called Clear seen tweets and Clear all tweets at the bottom of each column. Use them! Don't just mark your tweets, but clear them all! Don't waste your time re-scanning tweets you've already seen before.

That's it.

That's how I stopped wasting my time with Twitter.

There's more to learn about using TweetDeck and Twitter, and I recommend checking out this post too: All your TweetDeck questions answered.

(picture by carrotcreative)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Communication = Information * Relationships
Twitter Top 100 for Software Developers
Top 100 Best Books for Managers, Leaders & Humans

Great Managers Have No Secrets

In an earlier post I wrote that most problems in software projects are the result of bad communication, and that good communication is the result of good information and good relationships. But how do we make good information available? Well, the main thing to do is to make sure that no information remains hidden.

When people lack good information, they will invent some information themselves. When they don't know how well their project is doing, they will try to guess. When they don't know how other teams are performing, they will make assumptions. When they don't understand what their colleagues contribute to the organization, they will invent their own reasons. And when they don't know about their manager's personal life, they will gossip about it.

To prevent bad information from flowing through the organization you have to give people good information. In The Great Game of Business Jack Stack argues that great managers share information with their employees. One reviewer of the book summed it up nicely:

Share numbers with your employees. All the numbers that have meaning, from profit and loss to balance sheet, from sales projections to costing standards. The concept is that the more employees know, and understand, the more they will partner and support the company's mission and goals.

Managers should strive to have no secrets. In our organization I made sure that a lot of information is available for everyone. They all can see who is working on which projects, which features, bugs and issues are being handled, and what the team members' evaluations are of those projects. Our people's personal time sheets are public for all, and so are the ratings they give to indicate how happy they were with their projects.

My next step will be to share more financial details about costs and revenue for each of our projects. In tough economic times it is particularly important to make everyone understand what the organization's financial performance is. As Jack Stack wrote in his book: only when employees care about financial figures, they will think of ways how to improve them.

Some great managers managers (like John Mackey, Chairman and CEO of Whole Foods Market) even argue that people's salaries should be made public, including their own. After all, if you cannot explain some employee's salary to everyone else in the organization, then how can you expect people to trust you as a manager?

I can agree with that. But I also understand that you cannot change an organization's culture overnight. It would be very unwise to start publishing everyone's salaries when there's no culture of doing so. But you have to start somewhere. Jack Stack lists ten "Higher Laws of Business" in his book The Great Game of Business, the last one being "Shit rolls downhill", meaning that change begins at the top.

Well, someday I hope to be a great manager. So... here we go... no secrets...

Many of you already know I have a boyfriend.
Some of you know I have two kids.
I once rode naked on a bicycle.
I never wanted to be a manager.
And if you want to know my salary, email me.

So, now you can stop guessing, assuming, and gossiping. Let's get back to building great software!

Oh BTW, what's your secret?

(pictures by Tim Morgan and helmet13)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Communication = Information * Relationships
The Complex Manifesto for Software Development
That’s Why We Need Managers! (But Only a Few)

Communication = Information * Relationships

Have you noticed that problems in software projects are (almost) always the result of lack of good communication? (Some would argue it is actually lack of good management, but read on and you'll see that's basically the same.) As the Chief Information Officer (CIO) in our organization it is my job to be interested in informational problems. But I believe my territory (information) is just one part of the following equation:

Communication = Information * Relationships

In Complexity: Life at the edge of chaos Roger Lewin writes that abysmal relationships are the root of organizational problems. But again, that's only half of the equation. Without information to share, there wouldn't be any valuable communication. And without relationships, there wouldn't be a way to share the information. (Seeing this equation makes me wonder why organizations don't have a Chief Relationships Officer (CRO) and a Chief Communication Officer (CCO) as well. But never mind, I'm always happy to expand my territories.)

In Quality Software Management: Systems Thinking Gerald Weinberg writes about the human interaction dynamic:

"As the number of people increases, the ways they can interact tend to multiply faster than you can control them."

It is a strange remark. Weinberg's quote seems to imply that there are ways to control people's interactions when there are only few of them. Maybe I don't understand what he was trying accomplish, but such a conclusion looks incorrect to me. People will interact with each other, whether you want it or not. Control is never possible, unless you lock them up in prison.

With his book Complexity and Management Ralph Stacey convinced me that top-down systems thinking is a management fad. Weinberg's diagrams may be useful to understand communication problems in an organization, but managers shouldn't think these diagrams can help them solve those problems. Managers cannot directly control a social system by adding or removing relationships, nor by enabling or disabling communication. Managers are part of the system themselves, and communication simply happens. They can draw circles and lines until their fingers turn blue, but diagrams will never properly represent what happens on and off the work floor.

Of course, this doesn't mean you can only stand aside, feeling helpless. I see two important responsibilities for managers:

1) Open up information
You must make information available and accessible. And in general, more is better. Give everyone access to the Internet, all network folders, project information systems, and source control systems. Make books and magazines available, promote your company's intranet, and publish time registration reports, project burn charts, profit & loss figures, and other kinds of corporate information. Withholding information is (in general) a bad thing. Don't just assume that nobody will be interested in something. You may be right, but keeping information to yourself is not a good thing, because people will communicate something, and it can only mean that other (mis)information will be communicated.

2) Cultivate relationships
Roger Lewin talks about cultivating relationships between people. Resilience and innovation in an organization are the result of people having good relationships with each other, so that information flows freely and undistorted. You have to make sure that people enjoy working together. Remove cubicle walls, have informal meetings, facilitate coffee and smoke breaks, and promote people having lunch and dinner together. And most important: let people solve their problems together. When there's a dispute about something, refrain from stepping in for as long as possible. When people find solutions together it will often make their relationships stronger.

Improved communication
Following the formula above, if all goes well, communication should automatically improve.

There's nothing you can do to improve communication between people directly.

Redrawing circles and lines in a diagram will not solve your organization's problems. But you do have something to say on the accessibility of information, and you do have some influence on the quality of people's relationships.

While writing this, I realize that a Chief Communication Officer would have nothing to do. A Chief Information Officer only needs to work with a Chief Relationships Officer to make a real difference together. However, given the number of flowering relationships I have noticed in our organization, the work of a CRO (in our case) might not even be necessary.

(pictures by Army.mil and myself)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Good Tools Are Not Agile, Not Customizable, but Adaptable
4 Top Posts on Discipline in Software Development
That’s Why We Need Managers! (But Only a Few)

How to Start Managing from 2,000 Kilometers

So, how do you assume management responsibility for a group of 40 people in a foreign country, most of whom you’ve never met before? That was my question when I traveled from The Netherlands to our office in Ukraine.

Well, here’s a summary of what I did…

Sit between them
I was pleased to see that the desk our people in Ukraine had prepared for me was exactly in the middle of the biggest room. I didn’t mind that the desk was falling apart on all sides. The important thing was that it was the best place to experience the dynamics of the projects they were doing, and all the actions required to produce great software (which, for unknown reasons, included unidentified objects flying over my head).

Attend meetings
I attended a few planning and demo meetings, and other types of gatherings. It told me how people work, how they behave, and how they communicate. I didn’t have to attend a stand-up meeting, as they were doing some of those right in front of me, while practically standing on my desk. I only had to listen while pretending to do some real work.

Present myself
I got everyone together and told them what my role is, and why I was now assuming responsibility for their results. I also told them how important our business unit is for the entire organization (which is true), and that we’re obviously the best looking business unit of all (which is perhaps not really true, but nobody corrected me).

Interview everyone
I set out to personally interview every individual in my unit. I asked everybody (more or less) the same questions. They were just 10 or 12 open questions, like “What do you like about your job?”, “What would you change if you were a manager?”, “Why did you come and work in our organization?”, “Who do you go to when you have a problem?” and “Is there anything I can do for you?”

Some people might have thought I was insane, interviewing almost 40 people in one week. But I think it is the most effective way to 1) get to know the people a little; 2) understand the organization; and 3) convey the message that I care about what they think.

Appoint managers
You cannot directly manage a group of that size from a distance of 2,000 kilometers. That’s what you need local managers for. In this case, my need for good managers did not require any significant changes. They were already there waiting for me, and doing a splendid job of making me feel welcome. But I can imagine that, in other organizations, this step might be the riskiest and most difficult part of such an organizational transition.

Socialize with people
We all have our weaknesses. And I admit that socializing is not my strongest trait. I prefer a good book over bars and discos, and when it comes to alcohol I’m one of the most boring people on the planet. Nevertheless, our Ukrainian colleagues were very good at entertaining me, despite my shortcomings. I have dined, bowled, skated, played pool, shopped, and cooked. And I’m glad we had plenty of time to talk about non-work related stuff with each other.

I even joined a few people to visit a banya (Russian sauna). However, I felt I had to politely decline one of the local customs, after seeing my project managers being beaten senseless with half of an oak tree. Though the oak leaves flying around my head did add something to the atmosphere in the sauna.

Keep contact
The biggest challenge will come when I’m back in The Netherlands. It is all too easy to concern yourself more with the people directly around you, instead of those at the other side of Europe. I am sure that Skype, Jabber, possibly Twitter, and several other tools will become indispensable to me.

But I will be sure to let you know how that is going to work out…

Note: somebody told me once that Ukrainian humor is different from Dutch humor. But I never noticed such a thing. I understood all their jokes, as they understand mine. (It can also mean that my parents are Ukrainian.)

Follow me on Twitter - Subscribe with a reader - Subscribe by email!

Latest, greatest and favoritest posts:
What Motivates (Some of) Us
I'm Out of Control
A Tasty Team Building Exercise