The 3 C's are: Communication, Communication, Communication! (Stolen directly from Mr. Barden, Donnie's high school baseball coach.) A major part of engineering success comes down to communications. What should we build, how should we build it, how can I plug into your system, how does this code work -- we spend an enormous amount of time communicating.
When in doubt, assume that you should be more clear and more explicit than you think you need to be. Just as a production system should have redundancy and fault-tolerance, so should your communication system.
We have a lot of communication channels, from informal face-to-face conversations to scheduled meetings to email lists to chat rooms to wiki pages. The chat room is a good place to broadcast a quick question that almost anybody on the team could answer. The middle of a meeting about something unrelated is not.
A great deal of what we communicate is feedback. Feedback should not be given nor received as a personal attack -- the point of feedback is to collaboratively work towards a better solution than a single person could reach alone.
We must always try our hardest to remember the principles of humility, respect, and trust when giving and receiving feedback. We trust that both the author and the reviewer have the same goal of working towards the best solution. When disagreeing, we disagree respectfully by taking the time to consider the other side's reasoning and allowing that different people may arrive at different conclusions from the same information. Finally, we have enough humility to recognize that each of us will often be wrong, and feedback allows us to collectively be right more often.
Our primary videoconferencing technology is Google Hangouts. Use it both for scheduled meetings and as an ad hoc communication channel when you need to share a screen or just chat with a developer in another location.
We use HipChat for general group discussion. The developer room is our channel for asking questions, having quick discussions, and casual chatter. Keep in mind that you should not assume that all developers will be reading all chat messages, especially in real time. If you want to make sure that you are including the team in a discussion, start an email thread or open a code review.
Don't be shy about using the chat room! Developers are in there because we're interested in participating in the group discussion. On the flip side, also don't be shy about leaving the chat room if you want to reduce your distractions. (Obviously, taking chattiness or reclusiveness to an extreme is discouraged, but find a balance that works for you.)
You should also feel free to break out into a private chat room if you plan to have an extended discussion that is not relevant to the group as a whole.
We use PagerDuty for managing our alerts. Hopefully, there will be few of these. Make sure that you keep your contact information current.
If you receive an alert, you should log on to the developer chat room to coordinate with any other developers who may be working on the issue. Regardless of seniority, the first developer responding is the "engineer flying" and (unless he or she explicitly cedes the role to another developer) is responsible for managing our response. Having multiple developers each trying to independently fix a problem is unlikely to end well.
After each alert, the "engineer flying" should file an outage report. The purpose of these reports is to identify any patterns in our outages and prevent future problems.
Email is a great medium for extended conversation or for an asynchronous question. It's much more likely to be read by the intended recipient than a chat message, and it's much more socially acceptable for the recipient to take more time replying.
When you're addressing an email to one or more specific individuals, you should always consider whether there's an appropriate email list to use instead. Seeing other people's questions and answers is a great way to share knowledge, and it's always possible that the person you are asking is not the first or the best one to provide an answer.
Generally speaking, you will belong to the general developer list, a team-specific list, and additional lists for the projects that you are working on.
If your application needs to send emails to developers, the recommended setup is to send messages to a project-specific SNS topic, which in turn has a project-specific email distribution list subscribed to it. With a few exceptions, try not to send automatic emails to the whole development team or to specific developer email addresses.
Our internal dev wiki is a good place for putting reference information that is useful outside of a single project.
Documentation about an individual project should be included with the project's source code in our repository. A readme.md file is a great place for giving a quick overview and instructions for using a project.
We try to avoid having too many standing meetings. It is always appropriate to question whether a standing meeting is necessary if you do not feel that you are getting value out of it. Even if the meeting produces some value, it is entirely possible that the frequency or the attendee list could be improved.
Each team has its own daily standup. These short meetings are for keeping the team synchronized and aware of what each member is doing and what each member needs. Give a short update (~30 seconds is fine) answering the following three questions:
For example, "Yesterday, I finished writing code for the ABC report and sent it out for code review. I'm going to start work on adding the XYZ page to the web application next, but I need the UX team to update the mockups before I can start working on the UI components."
Each week, we dedicate a couple of hours for general knowledge sharing.
Each Thursday, we have an "Increasingly Inaccurately Named Dev Lunch and Learn". These 1 hour talks are an opportunity for a developer to go in-depth about a topic he or she wants to share.
On Fridays during Dev Demos, 4-5 developers each give a short (~10 minute) presentation. These are often less formal than lunch and learns and tend to focus on current work, productivity tips, cool technology, or other focused topics.
In both cases, however, the only requirement for topics is that they be something that the presenter thinks will be interesting for the team to see.
As we are a distributed team, we need to put a bit of extra effort into holding meetings across geographies.
If you are scheduling a meeting that includes people in multiple locations, make sure that you include a Google Hangout on the calendar invite.
Try to get to the meeting a few minutes early to make sure that you can connect to the hangout successfully and your audio/visual setup works. Make sure that your microphone and speakers are on, configured correctly, and working!
For clearer audio, sometime you will need to manually manage the mute/talk function.
Remember that you can mute other participants if their microphones are picking up a lot of ambient noise.
Remember that meetings are expensive! Having an hour meeting with three other developers is the same amount of "developer time" as half of your work day. Worse, as any developer knows, meetings are excellent ways of interrupting "flow time", which is when we are at our most productive.
This should not discourage you from scheduling a meeting if it is the best way to communicate. However, it does mean that we have a responsibility to make sure that the meeting is productive. For example, if you are scheduling a meeting:
Have an objective in mind. What do you hope to accomplish with this meeting? If you can't answer that question, why are you having a meeting?
Put together an agenda of topics to discuss and stick to it. Digressing into a discussion relevant only to a subset of the meeting's participants is a great way to waste a lot of people's time. One good option for creating and sharing an agenda is Asana.
Consider delegating the moderator role if you need to resolve differing opinions. It can be hard to both run and participate in a meeting at the same time.
Make sure that somebody is taking notes. Distribute these to the meeting participants afterwards, especially if they contain new tasks. It's easy for a seemingly productive meeting to fail to accomplish anything if nobody remembers what happened.