I work as a software developer in a small company. When I joined the company it was a startup, and only 3 people were responsible for all the development activities. Things ran smoothly, and we were all on the same page regarding the projects and the work we had to do. However, since the team has gotten bigger (we now have around 12 Developers and 2 Project Managers that work from two different locations), it's no longer the case that everyone knows all the IT department activities.

Is it practical to compile a list of things that every developer on the team should know about the department? This might include items like the current tasks running, the current projects running, what each developer is working on, etc. How can we achieve something like this?

  • 2
    Hey iyad, and welcome to The Workplace! Stack Exchange is very different from a forum -- as explained in our tour page, we focus on getting good answers to specific questions to serve as a resource for people in the future. Discussions aren't a very good fit because of the way the site works, though I invite you to pop in to The Workplace Chat to ask people about it. Otherwise, if you could edit your question to focus on a specific question such as, "How much should employees know about what other people in the department are working on?" it may get good answers. – jmac Dec 11 '13 at 8:32
  • I've edited your question a bit to try to make it more answerable and less of a general discussion topic. Hopefully this helps! If you disagree with my changes, you can edit in some of your own. If you need help improving the question to get it reopened, you can ask in The Workplace Chat. – yoozer8 Dec 11 '13 at 17:07
  • What kind of company is this? If the company puts out commercial software there could be an internal IT department and a product development department that both have developers. What are the departments within the company at this point in time? – JB King Dec 12 '13 at 0:38

Is it practical to compile a list of things that every developer on the team should know about the department?

Sure, it's practical to make the list... it's just impractical to maintain it, especially as teams, their processes and their work shift.

In my experience across a few companies, written documentation of this sort gets out of date pretty quickly. The good part of this is that if people really need to know something, then they'll find it out during the process of doing their work. Better yet, good teams will naturally streamline this process by going "ugh, I wish I knew that earlier! What process can I implement to help future people in my position?".

Your management (and/or project management) should facilitate this by removing obstacles:

  1. Sprint retrospectives (or similar periodic process improvement meetings) are great. You might not see results right away, but it gets people in a mindset of refinement.
  2. "How are we going to prevent this issue in the future?" rather than blaming people for mistakes. Blame makes people hide issues, questions like this make them think of ways to improve the company.
  3. Your leads should spread technical items of interest. Your PMs should spread project items of interest. Your management should spread business items of interest. Your developers should focus on developing. Nobody can know everything that is going on; make your team comfortable with that inevitability by saying "these other people (you trust) will help filter all this info to the relevant stuff". The key there is of course building trust...
  4. By identifying rumors and squashing them.
  5. Make it clear what you the individual are doing/responsible for (have useful 1 on 1's). If someone doesn't know what they do, its hard for them to tell others, and it's hard for them to know what they need to know within the larger group.
  6. Get good tools (chat, wiki, etc) so communication is easier.
  7. Continually culling/questioning processes that give the illusion of structure without the benefits of collaboration.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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