Thinking about why I haven't blogged in a while, I realized I put a lot of effort into writing things at work. Things that aren't really confidential, but often somewhat project specific. When we first started building this team over a year ago I explicitly did away with most reports to help us discover what shape the team should be. A few weeks ago I finally asked the Ubuntu One team to start writing weekly reports to help broadcast knowledge across timezones and teams, and it struck me that some of the reasoning and content might be interesting to other people who are trying to manage distributed engineering teams. So here is a lightly edited version of the email I sent internally a few weeks ago. Do you manage or work on a distributed engineering team? I'd love to hear your feedback and suggestions. Here's hoping that I fixed the comments on my blog this time around :)
These weekly engineering activity reports will replace the weekly reports that the ops+ team was doing, and replace the daily standup summaries that the foundations+ team was doing. Each team is totally free to conduct their standup meetings using the format, time, and medium that works best for them - the standup is about your immediate work group doing planning for the day, the weekly report is about telling the rest of the team (and company, if they care to look) what you have been doing. I hope the status reporting we used to do on team lead voice calls can be done away with, and we'll be able to spend the voice calls really solving problems rather than catching up with old news - also the whole team will be able to read the status, not just the people who were live on the call. We humans operate at a variety of different cognitive and affective levels. We think about things like lifelong values, short and medium term goals, and immediate activities - but not at the same time. It's vital to spend time thinking and working at each of those levels. One of the things I love about this team is that we are a team of doers, not a team of talkers or dreamers or empty unimplementable ideas. The risk though, is that we never slow down enough to jump up a level or two and do a weekly review, and think about how our activity that week supports our goals for the next 3 months, directions for the next 5 years, and that patterns that are emerging. Over time I have found that forcing myself to do a weekly review, and write a report even if it's only for me really helps me find and maintain balance and job satisfaction. I value the ability to move fast, to adapt to change, to be non-linear, to just do it rather than wait for a committee. But I've come to accept that taking a few minutes to switch back out of action mode to reflect on the bigger picture is not just useless overhead, mental paperwork, it's a critical part of the process of being a creative person who *actually ships*. Don't worry, I still endorse the cult of the done! Also, I've increasingly seen and been told that people don't know what the rest of the team is working on - this is a both a testament to how hard communication is in an environment distributed over both timezones and geography and a tribute to the incredibly diverse set of projects we are privileged to tackle. But it can also lead to feeling isolated, to not really having a shared understanding or vision of how all the parts fit together. It's my hope that by doing these weekly reports together, we'll have a lot better understanding of and appreciation for each other. I've talked with the 4 team managers about these reports and gotten unanimous support. This next section is trying to clarify some intentions based on feedback and questions from them: The goal of this report is not to find scapegoats, to assign blame, or to point fingers. I don't think we have a problem with people not doing work. I think we have a big problem with people working their hearts out somewhat invisibly, and not getting sufficient credit for their work. The goal of this report is to massively increase transparency, and often transparency can introduce some feelings of vulnerability. That means if you have a bad week and get nothing done, everyone else will know - and I think thats a good thing. Not because people will point fingers, but because bad weeks happen and everyone should be able to know the real hard truth of whether progress is happening or not. It means if you spend 75% of your work helping salvage some other part of the project that ran into big trouble and doing customer support, and didn't meet your own plan for the week, everyone will know and join in appreciating you for seizing the opportunity to contribute to the overall team when it made more sense than sticking to the plan. It means if you spend two weeks doing work on an upstream project that massively improves our standing as thought leaders, and land zero branches in our own code, everyone will understand what you are up to and why it's the right thing to be doing; rather than silently wondering "why is Joe not producing any code?". A report is not a substitute for real time proactive action. It is yesterdays news. What does this mean? If the DB server is going to run out of room in 1 week, and Mary puts that in the report, and then the DB crashes next week, i wouldn't accept the excuse "but I wrote it in the report, and nobody did anything" :) There should not be items like "Joe: the release was late because the QA team did not give feedback" "Tom: I couldn't give feedback because the tests were busted, so the release didn't go out". Instead, there should be items like "Joe: missed the release due to a very short testing window, worked with Tom on the phone to debug test problems, escalated a lucid failure to the platform team, and finally got things uploaded 1 day late." The report is going to be read - but maybe not the same day you write it. Maybe the most valuable thing that comes out of your activity report is when Susie Newhacker joins the company in 6 months to work on a project, and scans through a bunch of weekly reports and discovers a bunch of valuable links and branches that you reported on this week. Maybe the most valuable thing is when you can approach your manager and say "look, we really need to change my core hours or change how rollouts are scheduled, I got pulled into emergency firefighting/debugging 6 times in the last 4 weeks and missed appointments with my family/friends each time". This email has gotten surprisingly long, but I hope it helps explain why I'm requiring weekly reports and why I'm convinced they are not just useless overhead. As we get some experience doing them, feel free to propose additions/deletions/changes to the template. I'm looking forward to the first activity report from everyone on Monday.
And here is the template I'm using for activity reports from each person on the team (managers also do a more big-picture report that talks about progress of various projects toward the overall roadmap):
- Number of branches landed
- One or two sentence description of each branch here, with a link
- Number of code reviews worked on
- Bugs or blueprints worked on and summary of each, with a link
- Number of packages uploaded to PPA or Ubuntu or Debian
- Upstream project contributions
- Please list any absence last week and planned absence in the upcoming 3 weeks (including travel, sprints, conferences, and holidays)
- Any other activities or achievements
- Did you get pulled into any emergency unplanned work? What was it?
- What is your plan for this week?
- /dev/commentary - this is your chance to highlight something that the whole team should know about - a tip, a joke, a book, a blog, a tweet, a concern, some interesting news, a wild idea. More than a sentence, less than a chapter, links welcome.