This posting is part of my “Thoughts on Employment” series, detailing some lessons learned and general musings from my career as a software developer on what an employer can do to provide an effective, productive and attractive work environment for highly effective software development teams. For an index of postings in the series, please read the series summary.
Being able to bounce ideas off other team members, ask for help with a problem that's over your head without repercussion, and having open relationships between all developer groups and the business/customers. These are all important.
When you hire a software developer, you’re paying someone to think and convert those thoughts into code. It's really easy to box yourself mentally, restricting your ability to find optimal solutions to the challenge at hand. So having an environment where people feel comfortable talking to each other about their plan of attack and "thinking out loud" about the problem goes a long way. But this means developers must feel like they won't be punished for spending time talking to other developers about tasks beyond their own. Personally, I found the easiest way to squash this collaboration is to over schedule the dev team, so that everyone feels like they have no extra time for anything - a behavior we'll talk about again, because it is good at negating several items on this list.
Beyond individuals in a team collaborating, dev teams should be able to talk to each other. For smaller companies, this isn't as much of an issue, but for the much larger employers, the us vs. them mentality between development teams seems to be rampant. I'm not sure how this happens in the growth of a company, but I suspect it comes down to management comparing the productivity of the groups and pitting them against each other by awarding budgets to better preforming groups (ie: raises, equipment, etc). So in the same way you wouldn't share the internals of your code with a competing company, dev groups start to become islands within the same company. This is even worse if they report under different management structures. (CIO vs CTO, etc)
And then, make sure developers have access to the people setting the system requirements, whether that be a product owner, marketing, or an end customer. If I'm developing some code based on a set of requirements and have questions about the intent of the feature, or would like to propose an alternative solution, I should have direct and timely (within a couple hours and no more than a day) access to the person who can give me insight into the intention, or pitch my proposed alternative. This needs to be someone with the authority to make decisions about the product. In other words, if we agree something should be done differently than the initial requirements laid out, this person should have the authority to say "make it so" and I can go merrily on my way. There are places where I've had this discussion, determined that a (sometime only minor) changes is in order, then been told "ok, stop all development on this while I get approval for the change. That will take four weeks." Or worse: "implement the current requirements and we'll come back and change it once we get approvals". Waste of my time, and your money - a lot of your money.
Instant messaging is a must these days for communicating between these individuals. At West Monroe and CSG we used Microsoft's platform (now called Lync), which integrated nicely with Exchange and Outlook so conversations could start with a IM session and transition to email, or vice versa, as well as kickoff a screen sharing session from your chat window. At Wayport we hosted our own Jabber service (since most people ran Linux workstations) and at InRule and Incapital we used MSN/Yahoo/AIM. Personally, I use the Trillian client, which support all of the open IM networks, and find I use it to chat with people in my larger professional network too.
In addition to IM, I’ve had mixed success with Yammer at a couple of places. I find it works better at smaller companies where people actually know each other, than at the bigger places, but this may still work if you align yammer groups with local workgroups, etc. With Microsoft’s recent acquisition of Yammer, this may become integrated into Lync and/or Sharepoint in the future.