The Importance of Teams in Software Engineering
Sorry I haven’t been blogging for a while. Last Fall, I switch to work on Bing Infrastructure and have been very, very busy (and having a wonderful time). The projects I’m working on include COSMOS and Autopilot. COSMOS is a petabyte store (working towards being an exabyte store) which runs over tens of thousands of inexpensive computers. In addition to reliable storage, COSMOS supports Dryad based computation with application development in SCOPE which is a SQL-like language. Some public papers include: SCOPE and COSMOS, and Partitioning and Parallel Plans in SCOPE and COSMOS. The Autopilot team in OSD (Online Services Division which includes Bing) makes hardware selections for our ever-increasing bunch of servers, networking, systems support, automatic deployment and load balancing. See Autopilot. I have been having a blast working with the team in Bellevue and a team in Beijing with lots of talented people.
Recently, I’ve been trying to pull the various sub-teams together and open up communications and camaraderie within them. This is an approach I’ve taken numerous times since the 1980s and I believe it is super powerful and important. The idea is SO simple that I am always amazed it is not more common. We pick a regular day of the week and meet for lunch on that day. Simply reserve a conference room and have everyone run to the cafeteria (or wherever) and grab their lunch. As people trickle into the room at a few minutes after noon, the discussion begins. Here are some basic rules:
1) You want to pick a team size of 10-25ish which has a set of common technology interests. It should include development, test, and program management.
2) No topic is off limits but it needs to be broadly interesting to the folks on the team. Realistically, this quickly settles into some challenge the team is facing, some architectural issue, or some customer issue. What I like to do is let it go wherever it goes but watch the folks in the room. Once in a GREAT while, some small group gets into something that is kinda boring the others and you need to steer the discussion back to one of general interest. After a team is used to the meetings, it happens less often.
3) One person at a time talks as the discussion moves back and forth. It is important to listen to everyone and let the discussion evolve. No one should dominate the time. The more senior people should contribute (they usually have lots of valuable stuff to add) but they shouldn’t talk for too long.
4) It is important to try and get as many people (senior and junior) to participate as possible. When someone fresh out of college and new on the team feels they can contribute to the discussion, they feel more like they belong. To ensure this is safe and OK, it needs to be understood that critical responses are not OK. Gently discussing where a proposal may not be the best for some concrete reason is great as long as everyone contributing can feel safe. Of course, healthy and safe teasing and joking around are fun. One thing I’ve learned (by screwing it up) is that you shouldn’t call on the shy people to participate. Sometimes, a really shy person would rather hide under the table than talk. If you call on them, they’ll stop showing up for lunch. Now, when they WANT to speak, it is OK to stop the table to listen (unless the folks at the table have already done the polite thing as they should). It is normal for me to look around the room through the hour and make a mental note of who has not yet contributed. If I have sufficient context, I may try to steer the topic to something near to their interests to make it easy and natural for them to chime in… that’s not threatening to them. When this goes well, you will find that in a team of 15 to 20 everyone (or almost everyone) will have participated during the hour.
5) As much as possible, it is good to not cancel the weekly lunch discussions. We all find crunches and deadlines. The team gets busy and has to work its butt off for a few weeks. Still, everyone needs to eat lunch and the emotional decompression with your friends (and talking about the fun challenges in your product) is a good diversion from tracking down those bugs.
6) I think it’s important to not prepare for the lunch nor to announce a topic for the lunch. If the topic is known in advance, sometimes people say: “That’s not my favorite topic” and blow off the lunch. If, on the other hand, they get used to not expecting to know the topic and that the sessions are fun, they will show up and it can evolve into something fun. Also, if you have announced: “Sam will talk about XYZ”, it gets really tough to handle when Sam is a bore. Not everyone is capable of keeping a lecture interesting. It is better to say that the lectures are not during the “Friday Lunch Discussions” but are at some other time. You will learn that having a pre-planned topic takes away from the team’s sense of ownership of THEIR time to chat together. If there is a speaker, their won’t be as heavy a participation and it is a different event.
I like the following definition of the word “Culture”. Culture is “the way we do things around here”. It’s my experience that once the expectations are set, the team just naturally behaves in accordance with how they are used to behaving. That means you can set this discussion group up and it just happens moving forward.
There are many positive results from having these weekly meetings. The members of the team get to know the some of the larger team better than they would have… healthy fun discussions make you LIKE your colleagues. With a team size of 10-25ish, there will always be folks you don’t know as well as you’d like to know. The discussion of the main challenges for the team can forge and evolve the shared vision for the team. It is essential that the broader team understand the big picture and then work down into some of the details of the other pieces.
For me, this is both a major investment and a really nice treat. I’m working to provide architectural guidance to all of COSMOS and Autopilot. It’s pretty hard to keep up with all of these efforts and the people involved in them. I’ve wiped out my lunches for the week. Monday is Autopilot’s discussion meeting. Tuesday’s is the COSMOS Store team. Wednesday this week was the first for the SCOPE Compiler and Optimizer team. [Thursday’s are my day to write quietly… like this blog entry.] Friday’s are the Execution Engine’s meeting. I am still trying to figure out which of these days will have TWO meetings so the Manageability team can have a discussion (and I will have to switch off between them).
Each time I’ve started a team going with this, there’s quite a bit of confusion before the meeting but afterwards we have a good consensus that it was fun and useful. For me, it allows a precious opportunity to learn about the technology, the people, and how the people interact with their technology. Sometimes, I can contribute some comment here and there which moves the way people think about the goals and direction of the product. Always, it gives me an opportunity to work to help all the members of the team to learn and grow. A healthy team is built out of people who are growing and stretching in their abilities. This requires all the members of the team helping their friends in that process.
While typing this blog entry, an email came through from a teammate wanting to start a small effort on a utility. The discussion at lunch yesterday encouraged him to push forward with an idea he and another teammate were thinking about. I’m going to meet with them next week and get to know them better. It is tough to quantify all the ways these discussion help the team!
Anyway, I just wanted to share this experience with you. Software is much more than just bits and bytes. Many times, it is building the caring and comfort that allows you to be friends with shared responsibilities and shared goals. Sharing meals and camaraderie make a big difference. An occasional beer is good, too.
Great to be blogging!
- Pat