Agile Management | NOOP.NL

Long Live the Panarchy

Big projects have a higher chance of failure than small projects, primarily for sociological and communicative reasons. Some sources even claim that the odds of successful completion of a project disappear almost completely with large-scale projects.

But I’m an anarchist, and an optimist. I believe we can solve these problems by breaking things down and then blowing them up. Figuratively speaking, of course.

Agilists and anarchists break up big projects into small projects, and they break up large organizations into small organizations. Then they blow things up by scaling the small working parts to similar-looking big working parts. An agile organization is the inverse of bureaucracy through top-down planning. It is adaptability through bottom-up growth.

With the rise of global markets, the Internet, social networks, and other network-like developments, there is a global trend that looks very similar to the emergence of agile organizations. On a transnational scale such a network is called a panarchy. I love the word, because it is just one letter removed from my natural state of mind.

The emerging complexity of our social and political structures, composed of many interacting agents, combined with the increasing importance of network forms of organization, enabled by technologies that increase connectivity, propels the world system towards a transformation that culminates in a global political environment that is made up of a diversity of spheres of governance, the whole of which is called panarchy. To clarify, global linkages between individuals and groups create transnational networks consisting of shared norms and goals. […] Panarchy is governance as a complex adaptive system of anarchical networks that relies on diversity and resists hierarchy in order to function and adapt.
“Panarchy: Governance in the Network Age” - Paul Hartzog

A panarchy is a system of overlapping networks of collaboration and authority. As an individual I subject myself not only (unwillingly) to the authority of my government, but also (willingly) to that of my bank, my Internet and energy providers, Twitter, Facebook and LinkedIn, sports and game clubs, non-profit and charity organizations, and foreign governments when I’m traveling abroad. (And other people can add religious and political organizations to that list.)

There are many sources of authority in the world, and as an individual I choose to subject myself to the rules and norms of any group or organization that I wish to participate in. The only one I cannot choose directly is my government. (Unless I pick up my stuff and move somewhere else.)

These days being an anarchist is not what it used to be. I now call myself a panarchist. A panarchist is an anarchist who is acting peacefully. Brian Marick, one of the original signatories of the Agile Manifesto, has similar ideas and calls it Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism. But I think the word panarchy is easier. And I hope the stickers are cheaper.

The rise of global network governance is a process that is to some extent shaped by states, but it is not controlled by them, and it is also shaped by corporations, individuals, non-governmental organizations, and other groups. It is as yet unclear if any one of those entities trumps the others, although realists would claim the state holds the trump card, and Marxists would claim that it is capital that is in the driver’s seat. History has shown that ultimately it is the people who are in charge, and the new connective technologies have only increased their power and ability to organize collective action.
“Panarchy: Governance in the Network Age” - Paul Hartzog

We can now understand why true agile organizations are panarchies. They have multiple sources of authority within the agile organization, including those dealing with architecture, GUI design, project management, and infrastructure. Each team can subject itself, willingly, to the rules and norms of some specialist groups. But they can also form such functional teams themselves, or simply decide to do everything inside their own team. There is plenty of freedom to be anarcho-syndicalist or peacefully anarchist. The only choice people usually cannot make themselves is that of line management. Unless they move to another organization.

A panarchy is an organic approach to organizational design, resulting in a fractal-like structure of small hierarchies which are all superimposed on one another in one big network. And because it favors scaling out over scaling up, there is no end to the growth of a panarchy. In fact, a worldwide panarchy is already in place. It is called the United Nations. As an anarchist I complain about its bureaucracy, and the less it does the better. But being peaceful I’m willing to accept it for what it is. After all, which other planet can I go to?

(Note: if you find this interesting, please attend my session at Agile 2010, on Thursday, August 12.)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Choosing Authority Levels for Team Members The Optimal Team Size is Five Rubber Chicken Management

Diversity? You Mean Connectivity!

The approach some people have to the issue of social diversity is rather simplistic. Their idea of “adding diversity” to a software team is usually limited to attracting more women. It is an approach based on stereotypes about gender differences, and, from a scientific perspective, it is completely outdated (see: “Out with the pink and blue: Don’t foster the gender divide” - NewScientist).

“There’s a lot more to diversity than the shape of ones genitals.”
The Future of Management – Gary Hamel.

It has been noted by management experts and complexity scholars that a person’s performance is determined, to a large extent, by the system in which he is set to work. And social network analysis has revealed that this performance also depends on the person’s connectivity with other people in the social network (see: The Hidden Power of Social Networks – Cross/Parker).

This means that, when you hire a new person, one of the most important things to watch out for is how this person will connect to other people in the organization. Preferably, you want these connections to be of a different kind than the connections the existing team members have been able to establish, because diversity in connectivity has the highest impact on competence and performance in your team. Whether the person is male, female, dark, white, single, married, big, or tall, is probably irrelevant.

This means, when hiring a new team member, right after checking for competence, you should check for a person’s connection-making capabilities. For example, by checking what kind of connections she made in her previous job; the kind of connections she prefers in her social life; the sources she uses to increase her knowledge; the way she approaches the receptionist, the HR manager, and other people in your organization; and the way this person can get along with the team she is likely to join. That means you check this stuff before you sign the contract, because these are all indicators of the real diversity the person will add to your team.

Diversity is not about a person’s genes. It’s about a person’s mind and her connections.

(image by batega)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Choosing Authority Levels for Team Members The Optimal Team Size is Five People over Process: a Universal Law

Every Team Must Be a Value Unit

I really like our system administrators, but I think I am their worst customer. It’s not that I’m behaving badly. (Well, usually I’m not.) It’s just that my aura has an unpredictable effect on electromagnetic fields. People have seen reliable software crash whenever I passed by, and even the sturdiest operating system has an increased tendency to reboot unexpectedly in my presence. And remember those many times you saw a fail whale on Twitter? Yes, that was probably me having logged in before you. That’s why I like our system administrators so much. Because no matter how many problems I generate for them, they always treat me as a customer.

It is often claimed that cross-functional teams solve the problem of local optimization, which happens when functional teams optimize their own efficiency. This hurts the overall performance of the business. For example, a testing team may optimize testing procedures, making sure that all testing for a project is performed in one short period of time. Such an “efficient” practice doesn’t take into account the dramatic effect this has on the development and support phases of the projects. But is this really a problem of functional structure? Or is it an example of the testing team not treating the development and support teams as their customers?

The opposite problem is that cross-functional teams tend to optimize for their own projects, which can also hurt the overall performance of the business. For example, there may be problems when different project teams all decide to choose their own architectures and 3rd-party components. This increased variation of technologies makes it very difficult for the organization to support all those projects. And I’m sure that, when I allowed all our project teams to purchase their own computers and install their favorite operating systems and development environments, our friendly team of system administrators would skin me alive. With a screwdriver and a soldering iron.

But nobody in our organization would dream of inviting a system administrator into their cross-functional teams. And that’s not because we don’t like them. It’s because communication within the team of system administrators is more intensive than their communication with the project teams, even though infrastructure is an important part of many of our business solutions. Therefore it makes more sense to keep these people together in their own functional group, despite the communication penalty paid on any cross-functional communication.

What’s important is that every team, both functional and cross-functional, should see itself as delivering value to a customer, no matter whether that customer is an internal or external one. Our team of system administrators sees itself as a small business unit that tries to serve their customers, by delivering something valuable. And that’s why we like them. They make the other teams feel important, because to them we are important, no matter how often I crash our systems or bring down our servers. Functional teams and cross-functional teams should be run as little value units, and there is no limit to the number that can be formed.

(image by Josh Pesavento)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: When You Are Rejected About Project Success and Failure I Follow My Rules, You Follow Yours

Cross-Functional Teams Don't Come Free

How should people be grouped together? Basically there are two main options to choose from: group people by similar function or by similar business.

Grouping people by similar function means that you put developers with developers, testers with testers, and project managers with project managers. Such groups are called functional units, and the driving motivation behind this kind of structure is efficiency and functional learning. After all, it is easiest for writers of user stories to learn how to be efficient user story writers when they’re all put together in one department called User Story Writing.

Grouping people by similar business means that you put everyone together who works on the delivery of the same business value (the same feature, the same product, or the same customer). Such groups are sometimes called cross-functional units, because all people involved in the same project(s), from user story writers to binary assembly deployers, end up in the same group.

Good communication is both hard and crucial for any organization. It is therefore imperative that we let communication be one of our guiding principles when choosing between the two variants.

Which people need each other most often?

The ones with the same job titles?
Or the ones working on the same project?

If you were to analyze daily communication between employees it would quickly become clear that most of that communication is oriented around the business, and not around the function. People with different functions but working on the same projects need to communicate more frequently than people with the same functions who work on different projects (see figure). We can thus conclude that, for projects, cross-functional teams are a more suitable solution to the grouping problem.

 More communication within projects than within functional groups. 

It has been reported that, in organizations where people are grouped by function (sometimes referred to as functional silos), there are too many dependencies between the functional teams. Delivering even the smallest piece of business value (like one feature of a product) requires communication and co-ordination across multiple teams. Functional silos therefore have a high interaction penalty.

However... when you build teams across the functional silos, and not inside the silos, the interaction penalty is lower, but not zero! There are three problems with cross-functional teams: suboptimization at the project level, inefficiencies due to lack of coordination across projects, and reduced expertise because of limited knowledge sharing across specialists [Reinertsen 1997]. So it appears that with cross-functional teams the penalty is paid for synchronization of standards, methods and approaches within one functional discipline across different teams. For example, it will take a quality assurance manager more effort to co-ordinate best practices in testing, when the testers and QA people are spread over multiple teams. But the price being paid here is generally lower than in the case of functional units.

There are several other advantages to cross-functional teams (varyingly referred to as feature teams, project teams, organic teams, or product teams). Several experts report improved design decisions, reduced waste from hand-offs of intermediate products, improved speed, improved adaptability, simplified planning, and focus on delivering value.

But remember, unlike the Dutch score at world cup final, the costs of having cross-functional teams will not stand at zero!

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

(image by Jayel Aheram)

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Widen People’s Job Titles T-Shaped People How to Grow: More or Bigger?

3 Aspects of Team Boundaries

People tend to form groups. And when a group is small enough, and has a shared purpose, we may call it a team. The concept of a team is very useful, because it is a way of identifying a number of people as one entity. In psychology they call that “chunking”:

The idea of “chunking”: a group of items is perceived as a single “chunk”. The chunk’s boundary is a little like a cell membrane or a national border. It establishes a separate identity for the cluster within. According to context, one may wish to ignore the chunk’s internal structure or take it into account.
– Gödel, Escher, Bach (Douglas Hofstadter)

In my own organization, with many small projects and dozens of developers and testers in multiple locations, team formation has always been a challenge. We’ve changed our team formation approach more often than Madonna changed her image. But management of team boundaries is an important part of a manager’s responsibilities, and it’s important to try and get things right. After all, teams don’t operate well when people don’t know what the teams are, and who they can rely on.

There are three aspects to boundary management:

• the way teams are constructed;
• how individuals relate to teams;
• and how teams change over time.

Self-selection of teams is possible in organizations where people have a high level of “empowerment maturity”. In such an organization you create a pool of potential team members, and then you leave team formation to the group itself. There might be projects that many people want to be on, and projects that nobody wants to do. The great thing is that the group has to find its own rules for team selection, and as a manager you can just enjoy the heated discussions from the sideline. Self-selection of teams is something I have rarely seen in real businesses. It is worth considering, but you have to be sure that people understand how to form teams. One team of 30 developers and one team of 20 testers might not be a good option. Just consider the example of popular boy bands: Though they can have 30 members, in which case we tend to call them boy choirs, with such a size they rarely have the agility to keep up with trends in entertainment as much a small team can. So in order to increase their chance of success you might want to define and discuss some constraints on team formation first, concerning size, diversity, and other parameters.

How individuals relate to teams is another constraint you should take into account. Is a person allowed to be a member of more than one team? It is common for people not to perform as well as they could when they are asked to spread their loyalty across multiple teams. Mick Jagger never joined the Jackson Five to complement the Rolling Stones, and for good reasons. Such situations lead to task-switching, conflicts of interests, loss of commitment, and loss of motivation. Try and make sure that every person is dedicated to just one team. People cannot act as a team when they do not know what the team is. They may occasionally assist other teams, and help out with other people’s projects, or perform some duets, but each person should have exactly one base team to return to.

Finally, the time span of a team is also an important issue. Research shows that teams perform much better when they are long-lived. It is best for teams to exist for as long as possible, because it takes time for communication paths and rules in a team to grow and pay off. It also takes time for them to learn, as a team, which information is important for them and which is not. Just think of this: what is the best pop group ever? And how long did they stay together? More than a few years? Yes, I thought so. When projects in your organization are by their nature short, try and keep people together in teams with longer life spans, where the same teams work on one project after another.

(image by Chris Willis)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Widen People’s Job Titles How to Grow: More or Bigger? Network Effects: Waiting for the Tipping Point

Widen People's Job Titles

In my job as Chief Information Officer I have sometimes clashed with HR people over the chaotic growth of job titles in some parts of the organization. For business units as small as 10 people I saw never-ending streams of job titles flying by, like Content Developer, Content Manager, Web Editor, Web Designer, Interaction Designer, Front-end Designer, Front-end Developer, Web Manager, and Front-end Manager. I’m sure Interaction Developer had slipped in there somewhere as well. What was the use of all these different titles? I have no idea. And neither did the ones involved. I repeatedly told people that having fewer job titles is better. And all those developers and designers could have been called Esteemed Employee, as far as I’m concerned.

The team I’m working on has four great people in it. One of them knows all about the API that we have been developing. He decides what the interface looks like, how it is deployed, and how it is kept consistent over multiple releases. He is our leader when it comes to our programming interfaces. The second person is our youngest team member. But he has already proved himself as a promising architect. It won’t surprise me if he soon takes the lead in that area. Our third team member knows all about social media and e-commerce. He is our leader when it comes to on-line marketing and communication strategies. And finally, yours truly plays the role of the Product Owner, making decisions about features and priorities, and keeping the others busy so they don’t get bored and start blowing things up.

Each of the members in our team is a leader. We play roles that match our specialties, but they are not our job titles. We have no formal titles for Interface Programmers, Software Architects, Marketing Consultants or Product Owners. In fact, we take over each other’s roles whenever the need arises. (And this is a real necessity with me traveling up and down between conferences around the world.)

For improved organizational adaptability I believe it helps not to lock up responsibilities in job titles. Instead, you need to keep those titles as widely applicable as possible. People’s official job titles don’t change easily (sometimes only once every few years); therefore it is wise to decouple job titles from day-to-day responsibilities. For example, the title Software Engineer gives you more freedom in moving responsibilities around than the title Information Analyst. Even when someone asks to be called an Information Analyst, tell her that her contract will say Software Engineer, and that Information Analyst will be her role. For now.

The wide job titles can be used as formal boundaries for the informal roles. For example, the job of a Software Engineer can include anything ranging from design, development, and testing, to project management and support. Therefore, a Software Engineer in your organization might be allowed to pick up a diverse bunch of roles like Programmer, Tester, Support Engineer, and Business Analyst. But no person with a job title outside the boundary of Software Engineer (like Account Manager or System Administrator) would ever be given such roles.

Flexibility of people is exactly the reason why Scrum calls everyone simply a “Team Member.” It underlines the requirement that people feel a responsibility to do anything needed to ship their product, no matter their official job titles. Nobody should be able to say “I won’t do that. It’s not my job.” If releasing a successful product involves cleaning your customer’s keyboard, then cleaning keyboards is your job. Some organizations even go as far as to have just the title “Associate” for everyone in the company. It teaches people to be flexible while getting things done.

Note that the idea of widening job titles actively supports the concept of generalizing specialists. People should specialize in something, but they must be flexible enough not to claim exclusive job titles in support of their specialization. Such specialist job titles would mean responsibilities get locked into the title, and into the person. And that’s not what you want in an adaptable organization.

What you want is a small set of job titles, and perhaps a few guidelines on which informal roles go with which titles. Any initiatives that tend to increase the number of job titles in the organization, and requests to formalize roles and responsibilities, should be nipped in the bud.

For years my job title has been CIO, which is a great title because the letters can stand for almost anything. (Depending on the context the “I” has stood for Information, Ideation, Imagination, Innovation, Inspiration, Insubordination, Interaction, Intimidation, Illustration, and Idolization.) But the things I’ve specialized in, and the projects I did, often had nothing to do with my title. It was just stuff that had to be done.

(image by the thirty third)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: The Nonsense of Leadership (Princes and Priests) Some Day Kanban Will Fail 75% of the Time Managing Risk vs. Managing Yourself

Hyper-Productivity, or Autocatalysis

The day I wrote this text I had been drawing screen designs with Paint.NET. The only reason is that, in our team of five people, I happen to be the one with above-average drawing skills, which enables our developers to deliver a good looking product faster. Similarly, my work as a manager (and part-time designer) is sped up considerably by our architect, who excels at turning my designs into readable API documents, which tends to impress the customers that we talk to. At the same time the architect’s job is accelerated by our developers who seem to be producing code at the speed of thought and verify his ideas almost before he has finished showing his PowerPoint slides. It seems we are not just a team. We are an autocatalytic set.

An autocatalytic set is a system in which the agents reinforce and accelerate each other’s productivity. For example: suppose there are a number of molecules in a nice and warm pool of acidic gloop. Some of these molecules will participate in chemical reactions, thereby forming new molecules. And these new molecules in their turn also participate in chemical reactions. Schematically, one can draw a picture like this one:

Each molecule catalyzes, and is catalyzed by, at least one other molecule

Each molecule in the pool is a participant in a chemical reaction. But each molecule is also the product of another chemical reaction. We can imagine a set of molecules where each reaction is being accelerated by one of the other molecules (a catalyst) in the set, while the catalysts themselves are likewise products of chemical reactions reinforced by other catalysts. In short, the entire set of molecules is catalyzing itself. It is an auto-catalytic set.

Theoretical biologist Stuart Kauffman has shown that the forming of such an autocatalytic set is mathematically almost inevitable when diversity and connectivity are increased in a network. Such a heterogeneous system is self-sustaining. It has no need of anything else but itself, and a little energy from outside. In fact, there are suggestions that autocatalytic sets contributed significantly to the formation of life on Earth.

The principle of auto-catalysis is important. Not just for complexity theory, but also for me and my team. As more diverse people are added to the team, heterogeneity in the team increases. More team members are then able to play the role of catalyst for the work of some of the other team members, until at some point all work in the team is catalyzed by one or more of the others.

The catalyst is important because the project is always in a state of flux. Someone who can help a project to jell is worth two people who do just work. – Peopleware, Tom DeMarco, Tim Lister

I have a strong feeling that autocatalysis could be a scientific explanation for the “jelled” teams Demarco and Lister wrote about, and the “hyperproductivity” of software teams that agile expert Jeff Sutherland has frequently referred to. And even if I’m wrong, it still makes an interesting case for support of diversity, connectivity, and specialization in software teams.

On the day I wrote this text our team had a planning meeting, and we all noticed how fast we were going with only three weeks left for our product launch. Probably none of us thought: “Wow, we sure are auto-catalyzing nicely these days,” but we certainly felt that each of us was contributing to the productivity of the team. And I’m sure that the question “How am I helping the others go faster?” could have been answered easily by each of us.

(photo by cod_gabriel)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: The 9 Capabilities of Communicators It’s Only Communication When There’s Verification Discipline * Skill = Craftsmanship

Be Selfish... Work Together

I am a selfish person. Though I gladly do things for other people, and give stuff away for free, I tend to do that when I believe I’m being good to myself. The pursuit of my happiness has led me to offer jobs to unfortunate unemployed souls who needed a second chance, to give projects to people in desperate need of experience, to buy stuff from people in poor countries, and to be a supporter for Amnesty International. All because I’m selfish.

Genes are selfish too, as Richard Dawkins pointed out some decades ago. But, despite their selfishness, in the human genome 1,195 genes cooperate to produce the heart; 2,164 genes team up to make white blood cells; and 3,195 genes are jointly responsible for the human brain. They are teams of selfish genes, evolving together because, in all their selfishness, they figured out that it pays not to be on their own. It increases their chance of survival in the harsh environment of the gene pool.

An interesting form of teaming up within one species is found in the ants called Pheidole pallidula, which consists of small ant workers and large soldiers ants. When an intruder attempts to enter the nest, the worker ants pin down the intruder, while they recruit a soldier to decapitate the victim. (Don’t you just love the things teams can learn from nature?)

There are also many forms of teaming up between different species. One example is lichen, which is a partnership, or symbiotic association, between algae and fungi. The algae are photosynthesizers, capturing energy from the sun, while the fungi have great water-storage capabilities. This symbiotic relationship enables lichen to survive in barren environments. The team of two species can do what neither of the individual species can do alone.

Selfish cooperation is a matter of costs vs. benefits, where the small cost of giving or sharing leads to greater immediate or deferred benefits. Some call it reciprocal altruism, or win-win reciprocity, or you-scratch-my-back-I’ll-scratch-yours. It is why many jewelers in Antwerp have snuggled up and settled together in a few streets called the Diamond District. It is why fierce competitors like Google, Microsoft, and Apple are regularly seen to work together. It is why I’m answering people’s questions for free, promoting the books of my competitors, and offering jobs to suicidal kangaroos.

The root cause of the paradox of competition vs. cooperation (sometimes referred to as coopetition) can be traced back to the 235-year old book The Wealth of Nations, by economist and philosopher Adam Smith. He described division of labor as the concept of people working together, and specializing in different tasks, while still working for personal profit. And, as if guided by “an invisible hand,” the whole system then tends to improve the lives for everyone involved.

It is the same in organizations. Employees are competitors because they are hired individually. They frequently have eyes for the same job openings, the same cool projects, the same management positions, and the same parking space right near the entrance to the office building. But people team up together because it makes them more productive, gives them more joy, and better end-of-year evaluations.

We are all selfish. And the smartest selfish people understand that it is in their own self-interest to work together and be nice to each other. This coincides with the discovery of mathematician Robert Axelrod, who noticed that the game strategy Tit-for-tat, which tells someone to play nice as long as the competitors play nice as well, is one of the most successful survival strategies in games and in nature. It also coincides with Christopher Avery’s observation that teamwork is an individual skill. And philosopher Ayn Rand wrote books and essays on what she called the virtue of selfishness. Though her rigid doctrine has been criticized by many, at some level she did have a point.

These examples all tell the same story: Adam Smith’s invisible hand gently pushes people into cooperative behavior, because they all want the best for themselves.

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: The 9 Capabilities of Communicators Communicators: 2 * Three Types of People The Nonsense of Leadership (Princes and Priests)

Network Effects: Waiting for the Tipping Point

Twitter changed my life. As an introvert I have never been eager to talk about myself. But on Twitter it’s different. At times it seems the channel from my brain to my Twitter feed is wider than the one between Holland and Britain. And I have to take care that my social networking activities on-line aren’t taking over my “normal” life in the physical world, where my off-line social network has a size comparable to a meter box.

Research into network theory and social network analysis has uncovered a number of interesting phenomena in (both on-line and off-line) social networks. For example: a tipping point is the moment in time when something which was previously rare suddenly becomes widespread across an entire population, like the popularity of the Avatar movie, the Susan Boyle video, the Harry Potter books, or… my book. (I’m Twittering about the book until my fingers turn blue, so I’m sure it’s not my fault when it won’t fly.) In physics the tipping point is called a phase transition, but the meaning is the same: a sudden transformation of a system from one state to another.

A second example is the strength of weak ties, which says that information often better reaches populations in a network through many weak connections instead of few strong ones. Twitter followers are a perfect example of weak ties. They sometimes talk to me, but they never ruin my good mood with birthday party invitations.

And then there is the example of the long tail, which says that the sum of the value of sparsely available information can be larger than the value of stuff that is ubiquitous throughout the social network. Or, in other words, the Twitterers with few followers are together more powerful (and from a business-perspective more valuable) than the few with many followers.

But I think that one of the most interesting phenomena in small-world networks is the homogenization effect. Researchers found evidence that the long tail effect does not mean that people’s attention is shifting from the “head” (the most popular stuff) to the “tail” (the least popular stuff). Instead, it is the other way around: in a well-connected network information which gets copied around, gets copied around even more. What is popular becomes ever more popular:

It is a phenomenon known to economists as the Matthew effect, after a quotation from the gospel of that name: “For unto every one that hath shall be given.” […] easy digital replication and efficient communication through cellphones, email and social networking sites encourage fast-moving, fast-changing fads. The result is a homogenisation of tastes that boosts the chances of popular things becoming blockbusters, making the already successful even more successful. – Richard Webb, NewScientist

Homogenization in social groups, in societies, and in organizations, is the mechanism that enables shared culture, fads, and fashions. It is why, despite tremendous diversity in the social network, many people start liking and disliking the same things. It is why there’s a good chance that all development managers in the world will either love my book or hate it. Some researchers call it “social contagion”: the carrying over of ideas, likes, dislikes, and desires, from our friends, and from our friends’ friends.

It is becoming clear that a whole range of phenomena are transmitted through networks of friends in ways that are not entirely understood: happiness and depression, obesity, drinking and smoking habits, the inclination to turn out and vote in elections, a taste for certain music or food, a preference for online piracy, even the tendency to attempt or think about suicide. They ripple through networks “like pebbles thrown in a pond” […]. By being aware of the effects of social contagion we may be able to find ways to counter it, or use it to our own benefit. – Michael Bond, NewScientist

The same researchers found that the homogenization phenomenon usually loses its effect after three degrees in a social network. This means that you copy ideas from your friends, from the friends of your friends, and from the friends of friends of friends. But then the effect fades away.

Nevertheless, we can assume that there is a maximum of three degrees of separation in most if not all organizations, meaning that the homogenization of an idea, fad or fashion, can easily take place throughout an entire organization. This is something we can definitely use to our advantage.

And now you understand why I have been sharing so much of myself and my projects on Twitter. My 140-character brain emissions tend to increase the number of weak ties with people in the long tail, which has significantly increased the number of people separated from me by just three degrees or less. And now I’m eagerly looking forward to the tipping point…

(image by jurvetson)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: The 9 Capabilities of Communicators Communicators: 2 * Three Types of People It’s Only Communication When There’s Verification

The 9 Capabilities of Communicators

Based on our earlier observation of what communication really means, with signals traveling from one mind to another, and overcoming many obstacles on the way, I want to offer a new way of distinguishing communicators in an organization. It is an approach that doesn’t categorize people in three groups, but instead it differentiates between people’s capabilities:

Connecting
Some people are good at making connections with other people. They create many pathways through which communication can potentially take place. Such people may have many friends on Facebook or LinkedIn; they frequently attend meetings and conferences; and in the office they know just about everybody.

Filtering
Knowing many people doesn’t mean that you’re actually listening to all their messages. People who are good at filtering not only actively listen to other people’s social network status updates, and hallway chatter, but they also know which people and messages to ignore. Someone who is well-connected can be bad at filtering qualitatively, while someone with only few connections could be listening more intently and selectively.

Empathizing
Actively listening to people still doesn’t mean that you care about what they are saying. There needs to be some emotional association to someone’s messages in order to feel interested. For example, a socially challenged system administrator could care more about what developers are saying than a social savvy project manager.

Understanding
And then there has to be a real understanding of what is being said. You may be enthusiastic about some architectural issue in your project, and I may be able to empathize with you, but if I don’t understand anything about architecture then I don’t know what you mean, and I cannot respond properly to what you’re telling me.

Developing
Given what you learn, and what you already know, you are able to develop new information, and then pass it along to others. Right now I am developing this list of capabilities by connecting the dots between the works of Cockburn, Stephenson, and Gladwell, while adding my own thoughts to the cocktail. The capability of people for developing (creating, building) new information seems to be overlooked in the other models.

Managing
Some people are good at managing (categorizing and evaluating) existing information. They know what is important and what not, and they know to whom they should communicate something and, at least as important, to whom they should not communicate something.

Broadcasting
Then there are people who are experts at radiating information, whether intentional or not. They give away all they know, to anyone they meet, with either positive or negative consequences. Whether it is about projects, customers, management, or personal relationships, these people can, and will, tell you all about it.

Influencing
But those who send a lot of information may not necessarily be good at also influencing their colleagues. The silent but brilliant software architect, who rarely says a word, may be the best person in the organization, when he talks, to really make a difference. Such people transmit messages to fewer people, but (because of their status or power) they have a much higher success rate of convincing them.

Conversing
Finally, influencers are not necessarily communicators. I am told that some of my blog posts have influenced people, but I have not directly exchanged ideas with many of my readers. This means that I am incapable of steering their actions, and there is no understanding of what they do with the information that I gave them.

 

These are the nine capabilities of communicators in a social network. I think it is more realistic to view a social network as a system of people who communicate with various capability levels in each of these nine areas. These capabilities change over time for each person, and probably fluctuate depending on their areas of interest. This turns the social network into the complex system that it really deserves to be.

(image by The U.S. Army)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: It’s Only Communication When There’s Verification Yes, Good Managers Are Manipulators Why We Delegate: The Darkness Principle