I would like to launch an in-house user group/forum for the developers in my company, but I'm not sure how to get started.

We have several teams of developers spanning many technologies and levels of experience. I envision this as an opportunity for all of us to come together and share techniques, best practices, lessons learned, pain points, new technologies, or anything else a dev finds interesting.

This could also be a great way for new hires to integrate, learn how we do things, and share some of the expertise they bring with them.

This is my first attempt at anything like this and I'd like to do it right.

I'm interested in things like:

  • Driving participation
  • Keeping things interesting for both 20-year veterans and fresh, green graduates
  • Avoiding pitfalls known to be toxic to user groups

Has anyone done this successfully? If so, what can you share about the experience?

2 Answers 2


I envision this ....

While your vision is interesting, you really need to get every else's vision, first.

This is my first attempt at anything like this and I'd like to do it right.

Get over that notion. Seriously. Learning means making some mistakes and then correcting them. You must get used to the idea that an innovation must include a fair number of failures along the way.

Driving participation

You can lead a horse to water, but you cannot make it drink.

People will participate when they see value. You don't drive participation. You create value.

Keeping things interesting for both 20-year veterans and fresh, green graduates

Noble. Difficult. You may have to start with one or the other. Growth can come later.

First, get started with something -- anything -- that seems to work.

Then, when you have some core group that seems to be working, find ways to expand it.

You're selling an experience. Some people find work rich enough that they don't want anything more. Some people won't see the value in participating in a developer's group. Some people won't see the value in an in-house developer's group.

Start small. Grow incrementally.

Keep management at a distance. Ideally, not involved at all.

Poll potential members early and often. Be clear on what they want.

  • 1
    My plan was to ask everyone involved in the first meeting what they'd like to get out of this, and try to identify some common themes to use as a baseline for future meetings. Also, +1 for starting small and keeping management away. Dec 27, 2011 at 17:52
  • "ask everyone involved in the first meeting". You may want to start prior to the first meeting. Just meet with folks one-on-one.
    – S.Lott
    Dec 27, 2011 at 17:57
  • This has given me much to think about. Thank you for the advice. Dec 27, 2011 at 18:16

Agree with S.Lott. Keep things small. You can start off by recruiting some of your top developers to give brown bag lunch talks about some of the interesting things that they're doing in house. This type of informal discussions should appeal in several ways - senior developers can share hard-won lessons while the newer developers can find out about interesting projects that are happening within the company.

If there's sufficient interest over time, you can set up a recurring schedule of talks - perhaps weekly or monthly. After your in-house community has built up sufficient interest/momentum, you can engage management to provide support for the group - primarily geared towards attracting interesting outside speakers or helping the developer's group with resources (if necessary).

Not the answer you're looking for? Browse other questions tagged or ask your own question.