Is collaboration always productive?

I was at a meeting hosted at co-working space where I was suddenly struck by something. For a set fee a month, you get to use the co-working space in an open plan area. Walking around there, I saw a lot of people staring fixedly at their screens with their headphones on. This didn’t strike me as terribly collaborative or productive.

Developers like to tune everyone else out to focus on the problem at hand. You need to see the code, the more spiritual might even say feel the code, though I feel that’s a bit of the usual fluffy claptrap really. It’s about getting into the zone, and making sure you stay there so that you are productive. Being in an open plan office isn’t really conducive to that. You are constantly being bothered by interruptions; by people moving past your eye line, it’s loud. Thus, you see a lot of people with their headphones on trying to concentrate; this does seem to be completely at odds with what’s intended to be a collaborative space. You aren’t collaborating and you’re not as productive as you would be in a dedicated environment.

If you truly expect your team to be productive; then you have to make the office space fit your team; not some idealised vision of what a office should be. While it might look quite cool in pictures, having bean bags in the office is never a good idea. My entire team is distributed so we all work where we need to work, sometimes that’s in the office, most of the time it’s from home and we communicate over IM and VOIP. When we all choose to be in the office, that’s when we collaborate, I don’t try and force collaboration on the team. Even so, the office area is still very sparse; we just have a couple of big whiteboards on the wall. It’s quiet to the point of silence, but we schedule regular breaks where we collectively go for coffee, and this is when we start the collaboration process; sometimes moving back into the office to use the whiteboards.

When you’re building a product, at some point talking about what the product is has to give way to actually building it. An office space that favours interruptions isn’t going to help you do the work. Sometimes being left alone is what’s needed

Here’s to a productive day

Lewin

@quotidianEnnui

Image link: http://twitpic.com/dj27dh

Hiring your technical team

When you’re hiring a technical member of your team, it’s often very easy to fixate upon a certain skill-set, certain programming languages or even a certain number of years’ experience. You might even ask for industry specific experience.

More often than not, that just means you end up with a technical team that is less than the sum of its parts.

The key thing about a new hire is to think about the problem that you’re trying to solve, and how they’re going to fit into the current/new team. The skills that they currently have probably don’t matter as much as the skills that they can learn.

If we accept Malcolm Gladwell’s  claim about expertise; then you can reasonably expect to have an expert developer based on about 5 years’ experience. Technology is always moving forwards, and the last thing you want is someone who has 5 years’ experience doing the same thing over and over again; you want someone who has 5 years’ experience doing new things in technology each year. Bear in mind; that doesn’t mean shortlisting people with all the buzzwords of the day on their CV; that doesn’t make them developers.

When you’re interviewing; you could ask some silly “gotcha” technical questions; but I don’t believe it will actually help you find the right candidate. If they can get passionate about a technology topic, and speak at length about it, then that’s a better sign of someone who will care about the job they do for you. I always start with some questions that have no right or wrong answers just to see where that takes the discussion. If you start with something like “Apart from an IDE, what tools do you think are essential to you as a developer”; and yet they look at you with a blank stare; it probably isn’t a good start.

As part of our recruitment process, we always give a download link with a set of questions that they can do in their spare time and submit back to our company. It shows us really 3 things about the developer

1. Time management – I normally give them a deadline of about a week (always including a weekend). I want to see how they behave with a deadline; some people say I can’t do it by the end of next week because they have to visit their grandmother. That’s fine, they’re managing my expectations early. You have to be quite brutal here,
2. Analytical/Research skills – I wouldn’t expect my team to develop without access to their preferred search engine of choice. None of the questions are terribly difficult and I am expecting that you’ll use StackOverflow to find an approximate solution. I am constantly amazed as to how many people just can’t make the leap from there to the solution itself.
3. Pragmatism – a few of my questions are intentionally badly worded. Projects change scope on a weekly basis, how you approach your work from the start helps you cope with changes

In the end though, I’ve been very lucky. I hardly have to do any hiring. We have exceptionally low staff churn in the technical group.