Distributed Teams

Today, two blog posts collided with each other in my head:

Under the heading “Collaborating Across Boundaries“, Tessa Lau is contemplating which tools the computing community could offer to alleviate the challenges associated with distributed projects: It’s becoming harder and harder to cooperate – in my experience largely (though not exclusively) within the same company – with team members because people are chosen by expertise, never mind where they live.

On the same day, the social network XING reflects on this year’s nobel prize for economics: “XING und der Nobelpreis” (German :-/) explains that Oliver Williamson received the nobel prize this year for his work on transaction cost theory, the fact that the cost of conducting a transaction is one of the factors causing corporations to exist. I understood it like: Companies exist among others because they save transaction cost as compared to a same-sized community of freelancers. In a company, one doesn’t have to worry much about customers or suppliers, they are just there. As one might expect, there is a nice article at Wikipedia.

Social networks nowadays have a similar role for freelancers: They reduce transaction costs for individuals. That’s the link between XING and this year’s nobel prize.

Combining the two: geographic distribution imposes transaction costs that hit large cooperations about as much as individuals, but corporations are more rigid: while an individual could choose the second-best but geographically close specialist, a company has a certain department, say, in China. And if we are honest to ourselves: almost all of us are second best most of the time – is it really worth the effort? So, for knowledge workers: is geographic distribution a factor creating large companies, or is it rather inhibiting large companies?

Could this be the dawn of a new age of small, regionally oriented IT companies?

The elephant – again

A kick-off meeting to a project.

Situation: People already know each other, views have already diverged significantly. Over the past month, outside communication was strong (so expectations are huge), but inwards communication was weak (so opinions are scattered).

Complication: How to turn this bunch of minds into a team with “punch”?

Solution: Enter the story of the elephant… Continue reading The elephant – again

Architecture Challenges

Now this may or may not be rocket science, but introducing a systematic architecture approach has turned out rather tricky in the past.

What I’m doing now is working with the Architecture Challenges paper by Charlie Alfred.

In an environment where nobody has the time to “sharpen the saw”, introducing this as a mindset was tricky – and then again, eventually it worked out.

I’d like to thank the colleague in question to keep an open mind and, “despite” 20 years of industry experience, still experiment with a newbie program lead on such questions. Continue reading Architecture Challenges

Systems Thinking