Skip to content

Markus Gaertner (shino.de)
Syndicate content
Software Testing, Craftsmanship, Leadership and beyond
Updated: 7 hours 1 min ago

Working in a distributed company

Mon, 07/27/2015 - 22:15

In my courses, one or more of the participants almost always raise a question like this:

How do you set up a team across many sites?

Almost always when digging deeper I find out that they are currently working in a setting with many sites involved. Almost always they have a project organization set up with single-skill specialists involved. These single-skill specialists are almost always working on at least three different projects at the same time. In the better cases, the remote team members are spread across a single timezone. In the worst cases I have seen so far, it had been a timezone difference of ten hours.

I will leave how to deal with such a setting for a later blog entry. Today, I want to focus on some tips and tricks for working with remote team members and remote colleagues.

Tripit reported that I was on the road in 2012 for 304 days. I hardly believe that since I stayed at home for our newborn son Nico the whole June back then. (I think they have had a bug there.) But it was close. I have worked with remote team members and remote project teams in distributed companies since 2006. I hope I have some nuggets worth sharing.

Remote comes with a price

When it comes to distributed working, remoteness comes with a price. The hard thing most managers don’t realize does not stem from the difference in wage. In fact most companies I have seen merely out-source to far distant locations only because they take the wage savings into account – but not the social loss alongside.

The social loss is what happens when team members don’t know each other since they didn’t meet for a single time in person.

What happens with social loss?

Richard Hackman provides a some insights in his book Leading Teams. According to Hackman, teams are subject to several gains and losses over the course of their lifetime together. There are gains and losses on the subject of effort, performance strategy, and knowledge and skill.

When it comes to effort, social loafing by team members may stand in the way of the development of high shared commitment to the team and its work. For performance strategy, mindless reliance on habitual routines can become an obstacle to the invention of innovative, task-appropriate work procedures. For knowledge and skill, inappropriate weighting of member contributions can become a drag against sharing of knowledge and development of member skills.

All these three losses – social loafing, mindless reliance on habitual routines, and inappropriate weighting of member contributions – are more likely when team members are separated from each other. If they don’t know each other, they can’t make good decisions about distributing the work since people don’t know each other well enough to do so. They also are less likely to have a shared understanding of the organization’s context. They won’t know how to come up with better work procedures for the task at hand. And finally, the knowledge will be less likely shared among team members. It’s so hard to do when you have only two hours of common office hours between sites.

Besides the wage differences, these factors are hard to price. Thus, so it’s even harder to compare the costs of the decision to work in remote sites. You can make these costs a bit more transparent if you raise the question what it would cost to bring the whole team together every other week. That’s unlikely? That’s hard to do? That’s expensive? Well, how expensive is it in the first place to not do that? A couple of years ago I worked with a client that flew in their team from Prague every second week. They were aware of the social costs attached. And they were up to pay the price for it.

Though, that’s not a guarantee that it will work. But it makes the failure of teams less likely.

But what if you don’t want to pay that price? Well, there’s always the option to create teams local to one site. When you do that, make sure that you make the coordination effort between teams as less awkward as possible.

Video conferencing to the rescue

A couple of years ago, I found myself on a project team with some people set up in Germany and others in Malaysia. That’s a six hours timezone difference.

We were doing telephone conferences every other work day. And we were noticing problems in our communication. The phone went silent when one side had made an inquiry. Usually, that was an awkward silence. And more often than not – we found out later – that silence led to some undone tasks. (Did I mention the project was under stress?)

At one point, I was able to convince the project manager at my side of the table to talk to his pendant in the other location. They set up video conferencing. We coupled that with a phone call, still, but at least we could see each other. From that day on we had a different meeting. Now, we were able to see the faces of the others. We were able to see their facial expressions. We were able to see if they were not able to understand something that was said on the other end. And we were able to repeat the message or paraphrase it to get the point across. Certainly, the same happened for the other side. That’s what changed the whole meetings for us.

So, if you decide to set up remote team members, then also make sure they have the technology necessary to communicate and coordinate well enough between the different locations. One prospective client that I visited once had taken over a whole meeting room. The room was no longer bookable by persons in the organization. They had set up the various boards of all the teams in that meeting room. They also had a video projector and a 360° camera installed there. The whole set up was targeted to make it easy to have cross-site communication available. I can only urge you to invest in such technology. Your meetings will become more effective in the long run.

Transparency creates trust

Seeing each other during meetings is a specialization of a more general concept. Transparency related to work- and task-oriented data creates trust. I have seen work teams mourning over each other just because they stopped to know what “the other” team was doing. The trust also turns into distrust when there is a lack of transparency in certain regards, and the transparency you get just confuses.

Unfortunately, creating transparency also takes effort in most cases. You have to provide the numbers that others want to see like percentage of code covered by unit tests or net profit values of new features. In software, you will be providing those numbers maybe by another program. In non-software teams, you may need to find other ways to provide such information. Still, it will take effort.

Is that effort well spent? If my claim is correct, that transparency creates trust (lots of, actually), you should aim for the sweet spot between creating enough trust and effort spent on providing the necessary transparency. In other words, ask yourself the question, is the effort I spend on creating transparency well spent for the trust that we gain as a group?

A couple of years ago, Kent Beck raised another point in this regard. He said that he always tried to be transparent in every regard. Because hiding information takes effort. When you are completely transparent, you can save those efforts that go into hiding information and use it to provide value. I like that attitude.

One final thought: if creating transparency is indeed too effortful for you, remember there is always the option to work in a non-distributed setting. When you have chosen to work for a distributed company, the extra trust through transparency should be the price that you want to pay.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs

So, I went for the board

Sun, 06/14/2015 - 22:01

End of August two years ago, I announced that I was going for the AST board. I kept my expectations pretty low, and I am glad that I did. Two years have passed, so I figured let’s revisit that decision from back then. Long story short: I won’t go for another two years. Read on to find out why.

The secretary

For two years, I have been the secretary of the board of directors of the Association for Software Testing. Pretty nice sounding title, eh? Well, there are three in-person board member meetings a year. We also went from bi-weekly calls to monthly ecoms during my term.

Usually the in-person meetings are done over a weekend from Saturday morning until Sunday noon-ish. That’s where most of the decisions are made for the ongoing course. In between, we tried to get work done.

Well, we tried at least. Part of the problem is when you depart from the in-person meetings, and get back to your daily routine, many of the good intentions to move something forward are eaten up by daily business. That’s happened to me, that’s happened to other board members, and many of them admitted it. It’s bit of a tragic situation, considering that folks get elected for having a loud voice on twitter or in the community, but you don’t know for sure if they get anything done in a group of volunteers.

So, for anyone out there wanting to go for the board, keep in mind not to set yourself a too high target. Remember that you will be dealing with a totally mixed set of volunteers, and it’s very hard to predict if and how you can work together. Folks from different directions have different opinions about different things. It might be that you will totally rock the place. But in hindsight, after two years, I think that the context-driven testing community is set up with many opinionated people, that can make the “getting something done” side of business hard at many times.

So, why I’m stepping down?

Besides all the things that we kept rolling, over the course of the last year, I figured that being the first European board member is causing me much of stress. Usually I took Fridays to fly into board member meetings, and returned early mornings on Mondays when we had an in-person meeting. That worked to some extent with my schedule, and I think that’s based upon the company I work for, and the freedom that I could take there.

And I think after two years, I have seen enough to recognize that it’s way harder to participate in online discussions with the timezone difference. It’s way harder to contribute to the board discussions that we have online or in email, and so on.

In September, I also became a CST which made me life with keeping track of online discussions harder. When you’re in class for two or three days straight, you don’t return to your hotel room to read the updates from the day.

So, over time, I figured that I couldn’t put in the amount of time that I felt would be necessary. I also recognized, that it became harder and harder for me to contribute. That’s when I decided that the AST would be better off if someone else had the chance to step in.

It’s not all bad

But it’s not all bad. During the last year we made the decision to update the BBST course material, to move the website to a new system, and to form a group working on standards and certifications. I think these are good steps, and they were long overdue.

That said, I look forward to the new elected board members, and how they will continue the work of 10 years of board members that came before them. I leave the group with a whining and a smiling face.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Categories: Blogs